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