Grx September 2007

grx@gnu.de

1 participants
2 discussions

Re: GRX 2.4.8
by Maurice Lombardi 27 Sep '07

27 Sep '07

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

1 0

Re: GRX 2.4.8
by Maurice Lombardi 10 Sep '07

10 Sep '07

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

Grx September 2007