Arlindo da Silva a écrit:
> One of the historical features of GRX is the the notion of a
> Graphics mode. The current windows driver behaves in a rather
> unintuitive manner: one cannot increase the window size beyond the
> size specified at startup and when you shrink it, it simply clips the
> display; a more intuitive behavior would be to rescale the contents of
> the window and repaint it.
>
> My question for you: do you see any hope of having a Win32 (and X11
> for that matter) driver that allows one to resize the window and have
> its contents rescaled and repainted?
I have uploaded to the GRX site in the "More things" section a patch
http://grx.gnu.de/ReSize.diff
which is a step towards this goal, for both the win32 and the x11 targets.
It contains two test program to show how to work with it.
In this case the rescaling and repainting is made by the main program
which uses grx.
When you resize the window, the system only changes the maximum size and
the clipping size of the Screen context and of the Current context,
and enqueues a GRX event GRX_SIZE_CHANGED.
The calling program waits in a loop, recognizes the event, and clears and
redraws the window with the new scale.
the mousetst.c test program is event driven, and uses the GRX_SIZE_CHANGED
event himself.
the winclip.c test program is in a GrKeyPressed loop, and recognizes
the event by looking for the change of GrSizeX or GrSizeY.
You probably had in mind something more difficult: automatic repainting
by GRX. I have found functions for rescaling bitmaps, but I see two
problems for that
- rescaling looses information and degrades the drawing. This accumulates
with several resizings.
- If you want to draw further on a rescaled window, you have to rescale
all contexts in use. There is presently no book keeping of the contexts
in use by GRX. You can even create a temporary context or subcontext
in stack (using the last pointer "where" of GrCreateContext or
GrCreateSubcontext), and never destroy it explicitly, so that the
adress becomes invalid when exiting from the function where
it is declared.
The only clean way to overcome both problems is to have
a fixed bitmap, write the drawings on it in its original,
never modified size, and put to screen a resized version.
But I have no idea on how to do that: it is probably a major rewriting.
So no promise ...
Maurice
--
Maurice Lombardi
Laboratoire de Spectrometrie Physique,
Universite Joseph Fourier de Grenoble, BP87
38402 Saint Martin d'Heres Cedex FRANCE
Tel: 33 (0)4 76 51 47 51
Fax: 33 (0)4 76 63 54 95
mailto:Maurice.Lombardi@ujf-grenoble.fr
Arlindo da Silva a écrit:
> I am so glad that GRX is again being maintained. I have been using
> GRX on and off for sometime since the old MS-DOS under DJGPP v1. My
> current use involves the rework of the old xlibemu from DJGPP which
> hooks GRX with the X11R5 (yes, R5) allowing simple X11 clients to run
> without an Xserver. (There are other alternatives out there for this,
> but none worked as reliably).
>
> One of the historical features of GRX is the the notion of a
> Graphics mode. The current windows driver behaves in a rather
> unintuitive manner: one cannot increase the window size beyond the
> size specified at startup and when you shrink it, it simply clips the
> display; a more intuitive behavior would be to rescale the contents of
> the window and repaint it.
>
> My question for you: do you see any hope of having a Win32 (and X11
> for that matter) driver that allows one to resize the window and have
> its contents rescaled and repainted?
If you have read the announce on "Sanitized" GRX 2.4.8, you have seen
that a step toward this end was made by a patch
http://grx.gnu.de/archive/grx/en/mail446.html
that I had incorporated in grx 2.4.7,
which dealed with WM_SIZE windows events.
I discarded this part of the patch in Sanitization because it produced
crashes.
In fact the situation is better than I was thinking: these crashes
are due to a bug in the proposed patch, the usual confusion between
number of elements of an array and maximum value of its index.
I have thus put in the "more things" section a patch
http://grx.gnu.de/ReSize.diff
which restores a corrected WM_SIZE treatment,
and a test/mousetst program which uses it to to obtain proportional
scaling as you request.
You can play with it to get an idea.
This is however only a small step towards your goal.
The central problem is "who repaints ?", the calling program
or grx or windows behind the scene.
In the current situation, it is the calling program (the
simplest to implement).
When the running program receives a WM_PAINT event,
GRX only changes Sizes in GrScreenContext and GrCurrentContext, and puts
a GR_SIZE_CHANGED event in the GRX event queue, nothing more.
The calling program (mousetst) watches for this event
and clears and redraws the screen using GrSizeX(), GrSizeY()
to scale the drawing.
A variable GrSizeChangesContext is used to change
between old (clipping) and new (scaling) behaviour,
defaulting to 0 (clipping), not to break down existing programs
which do not expect this new behaviour, and thus do not watch
the WM_PAINT events and react accordingly.
Automatic scaled repainting by GRX is a more complex problem.
Any how, even if this is implemented, all application programs
would have to be written keeping in mind that scale
can change at any moment, every drawing should be scaled
with actual instantaneous GrSizeX(), GrSizeY(), as was
made fortunately by the original mousetst program.
Finally there is a great technical difference between increasing
and decrease the size with respect to the original given
by GrSetMode. All graphics information is stored in memory
in a bitmap which size is given by GrSetMode. Decreasing the size
by clipping (the default automatic windows behaviour) is just
putting to screen only a part of this bitmap, an easy task.
But all drawings by the program are made on the full bitmap,
and thus it needs not care to the actual size seen.
Down resizing needs rewriting the part of the bitmap which
is seen. Up Resizing would need to use a larger bitmap,
with a new GrSetMode probably.
This is only very preliminary. I have not even checked
carefully if there are not other adverse side effect
of the present patch.
Maurice
--
Maurice Lombardi
Laboratoire de Spectrometrie Physique,
Universite Joseph Fourier de Grenoble, BP87
38402 Saint Martin d'Heres Cedex FRANCE
Tel: 33 (0)4 76 51 47 51
Fax: 33 (0)4 76 63 54 95
mailto:Maurice.Lombardi@ujf-grenoble.fr
