Grx

grx@gnu.de

559 discussions

Re: GrBitBlt is slow, MinGW32
by Josu Onandia 05 Feb '03

05 Feb '03

I agree that GrBitBlt is very slow under Win32. I think other functions are slow too, such text painting, because all of them are based in calling SetPixel for every pixel, which I think is the root cause. I think you are right in your second solution, but I have some questions: - Why a DeviceIndependentBitmap? What advantages has over a CompatibleBitmap? - Why do you need synchronization between threads? Aren't they already synchronized? - This only solves the GrBitBlt, what about the rest of the driver? Is there a way to bypass the GDI and go directly to the graphics hardware? Is DirectDraw the solution? Is there someone brave enough to port the frame driver to DirectDraw? Too many questions ... :-) I'm still interested in this driver, and I'd like to colaborate, but I'm afraid I'm too busy right now. Josu Onandia > -----Mensaje original----- > De: Demmer, Thomas [SMTP:TDemmer@krafteurope.com] > Enviado el: miércoles 5 de febrero de 2003 12:05 > Para: 'Eike Lange'; 'grx(a)gnu.de' > Asunto: Re: GrBitBlt is slow, MinGW32 > > "Slow" is euphemistic :-) > When I ran test/speedtst I thought the program was crashing.... > > There are basically two approaches to speed up WIN32: > 1) Change all GrContext to something that is a GDI > object. Blitting from/to these things is quite fast, may be supported > by the underlying hardware, and probably breaks a lot of > existing user code that relies on having a memory map of > the frame. > > 2) Initialize the backing bitmap as a Device Independent Bitmap > and rewrite major parts of fdrivers/fd_win32.c + add the synchronization > between the main thread and the painting thread. > > As soon as I find the time I look into approach 2, I have a couple of > testbeds available by now to play with this independently of grx and to > understand how this should be designed. Anybody willing to > contribute or test can contact me off-list. > > Ciao > Tom > > > -----Original Message----- > > From: Eike Lange [SMTP:eike.lange@uni-essen.de] > > Sent: Mittwoch, 5. Februar 2003 11:13 > > To: 'grx(a)gnu.de' > > Subject: GrBitBlt is slow, MinGW32 > > > > Hi! > > > > Comparing the time of blitting from one context to another > > with different operating systems and same context sizes > > results in _boring_slow_ blitting on Windows (MinGW32). > > I'm using GNU Pascal on both systems. > > > > I just create a background context, draw a line in it > > and blit it into the foreground context. Doing it 10 times > > (selecting background, drawing, blitting to foreground) > > takes about one minute. With Linux, it is incredible fast. > > > > Is there a faster way with MinGW32? > > > > -- > > Eike Lange

2 1

Re: GrBitBlt is slow, MinGW32
by Demmer, Thomas 05 Feb '03

05 Feb '03

"Slow" is euphemistic :-) When I ran test/speedtst I thought the program was crashing.... There are basically two approaches to speed up WIN32: 1) Change all GrContext to something that is a GDI object. Blitting from/to these things is quite fast, may be supported by the underlying hardware, and probably breaks a lot of existing user code that relies on having a memory map of the frame. 2) Initialize the backing bitmap as a Device Independent Bitmap and rewrite major parts of fdrivers/fd_win32.c + add the synchronization between the main thread and the painting thread. As soon as I find the time I look into approach 2, I have a couple of testbeds available by now to play with this independently of grx and to understand how this should be designed. Anybody willing to contribute or test can contact me off-list. Ciao Tom > -----Original Message----- > From: Eike Lange [SMTP:eike.lange@uni-essen.de] > Sent: Mittwoch, 5. Februar 2003 11:13 > To: 'grx(a)gnu.de' > Subject: GrBitBlt is slow, MinGW32 > > Hi! > > Comparing the time of blitting from one context to another > with different operating systems and same context sizes > results in _boring_slow_ blitting on Windows (MinGW32). > I'm using GNU Pascal on both systems. > > I just create a background context, draw a line in it > and blit it into the foreground context. Doing it 10 times > (selecting background, drawing, blitting to foreground) > takes about one minute. With Linux, it is incredible fast. > > Is there a faster way with MinGW32? > > -- > Eike Lange

1 0

GrBitBlt is slow, MinGW32
by Eike Lange 05 Feb '03

05 Feb '03

Hi! Comparing the time of blitting from one context to another with different operating systems and same context sizes results in _boring_slow_ blitting on Windows (MinGW32). I'm using GNU Pascal on both systems. I just create a background context, draw a line in it and blit it into the foreground context. Doing it 10 times (selecting background, drawing, blitting to foreground) takes about one minute. With Linux, it is incredible fast. Is there a faster way with MinGW32? -- Eike Lange

1 0

GRX fonts
by Michael Dillon 31 Jan '03

31 Jan '03

Im trying to test out diffrent fonts with GRX, however i cant seen to figure out how to convert ttf or fon files into fnt files to use in GRX. Can you help?

2 1

Patch for MinGW/cygwin
by Demmer, Thomas 30 Jan '03

30 Jan '03

Hi list, here are (hopefully) my final words on the changes to vdriver/vd_win32.c The patch does the following: * It removes the ugly GRXMain construct. Instead, when the Win32 driver is initialized and setmode() is called, a helper thread and the graphics window is created. * If somebody tries to close the graphics window, a dialog pops up warning that this will kill the application. If confirmed, the application is terminated. The main thread is not suspended, this dialog is non-modal to the application. Implications: * demo/keys.exe now segfaults, because it tries to use the message queue before it is set-up. I consider this a bug in keys.c that one has to work around the same way as for the X11 case. Alternatively, the key and mouse routines should check for the existence of a graphics window and call setmode() accordingly. * For gpc you have to remove the references to GRXMain in pascal/grx.pas, and maybe in other places. * All other tests succeed under MinGW. * All test fail under cygwin when called from demogrx. Reason: demogrx calls system(".\\foo"); instead of system("./foo"); * All other tests succeed when called directly. * speedtst doesn't compile under Cygwin because <values.h> is missing (which is, funny enough, empty in mingw :-)) . Other: * If vd_win32.c is compiled with -DUSE_DIB (very experimental) support for a device independent bitmap of the graphics window is enabled. This works at least OK for the 24 bpp mode and seems to speed up BitBlts pretty much. There are up to now some issues in coordinating main and helper thread, but that seems to be only a matter of adding another CriticalSection() semaphore. This weekend I'll be snowboarding, it may take some time to implement... * If you change the $(AR) and $(RANLIB) lines in the Makefile to (all in one line) $(CC) $(CCOPT) -shared -Wl,--output-def=grx.def \ -Wl,--out-implib=libgrx.dll.a -o grx.dll $(ALL_O) $(ADDON_L) you get a nice dll and a link-lib. (Under bash, no ideas if cmd.exe groks $(ALL_O) ) this works with both 'CC=gcc' and 'CC=gcc -mno-cygwin' Happy hacking, Ciao Tom <<vd_win32.pat.0130>> <<grx20.pat.0128>> Thomas Demmer Kraft Foods R&D Munich Phone: +49 89 62738-6302 Fax: +49 89 62738-86302 Thought of the Day: A real friend isn't someone you use once and then throw away. A real friend is someone you can use over and over again.

2 1

Re: GRX2.4.5 and MinGW/Cygwin
by Demmer, Thomas 28 Jan '03

28 Jan '03

Mariano, see comments and questions below > -----Original Message----- > From: Mariano Alvarez Fernandez [SMTP:malfer@telefonica.net] > Sent: Freitag, 24. Januar 2003 21:47 > To: Demmer, Thomas > Cc: 'grx(a)gnu.de' > Subject: Re: GRX2.4.5 and MinGW/Cygwin > > Hi, Tom > > In general, I like your changes to the windows videodriver, because we > get rid of the special GRXMain entry point. It has some rough edges: > pressing the close button is catastrophic (at least in W98) and the last > app doesnt't get the focus when the GRX app end. But is a good start. > [Demmer, Thomas] Hmm, what catastrophy does happen? I only have NT4 and 2K, I believe the problem is that the message handler tries to dispatch a message to a non-exisiting window. > Some suggestions: > > - Setmode. Create the window_thread only if mp->extinfo->mode != > GR_frametext, and destroy the window_thread (if created) else. > [Demmer, Thomas] Hmm. If we destroy window and thread, there is no more chance to keep the window's content. What is the correct behaviour here? > - Detect. The detect function can be called more than one time, so it is > necesary to have a static variable to signal it and return TRUE if the > work was done. Move the InitialiceCriticalSection to "init" and add > DeleteCriticalSection to "reset". > [Demmer, Thomas] Well, my stupidity. It should be moved *all* to init(). That one is called only once, am I correct? > - Reset. Destoy the window_thread if was created. > > - WM_CLOSE. We need to maintain the close dialog, people must be warned > they are avorting the program. If user says yes, move the message to the > queue, and let abort the program in the input driver (the main thread) > mouse/w32inp.c. > [Demmer, Thomas] OK. Ciao Tom

2 1

Re: GRX modifies ParamCount, and ParamStr
by Demmer, Thomas 28 Jan '03

28 Jan '03

> -----Original Message----- > From: Eike Lange [SMTP:eike.lange@uni-essen.de] > Sent: Montag, 27. Januar 2003 15:44 > To: grx(a)gnu.de > Subject: GRX modifies ParamCount, and ParamStr > > Hi Folks! > > I'm using GRX with GNU-Pascal. Programs written under Win32 (mingw32) > which are started from a directory having spaces in the directory name > do not work properly. > > For example: > > c:\own files\my own files\project.exe > > Setting the title with GrSetWindowtitle (ParamStr (0)) > result in a title named "C:\own". > > Trying this out with GNU/Linux results in the correct name (including > all whitespaces). > > Can anyone help me? > > Eike Well, not (yet) really. The problem is in "vd_win32.c" where GRXLocalMain() builds the command line. Its approach is to split the command line at spaces, which is not sufficient. If you are brave at heart you may want to apply the patches I posted the other day *AND* change in the Pascal library whatever is necessary to eliminate "GRXMain" (and just call the equivalent of main(), what ever that is) to see if it fixes the error (it should). If you can wait a bit more I hope to have a slightly more stable version of the patches ready by this afternoon. Ciao Tom

1 0

GRX modifies ParamCount, and ParamStr
by Eike Lange 27 Jan '03

27 Jan '03

Hi Folks! I'm using GRX with GNU-Pascal. Programs written under Win32 (mingw32) which are started from a directory having spaces in the directory name do not work properly. For example: c:\own files\my own files\project.exe Setting the title with GrSetWindowtitle (ParamStr (0)) result in a title named "C:\own". Trying this out with GNU/Linux results in the correct name (including all whitespaces). Can anyone help me? Eike

1 0

Re: GRX2.4.5 and MinGW/Cygwin
by Demmer, Thomas 24 Jan '03

24 Jan '03

OK, here we go: GRX builds under Cygwin and MinGW, I have tried and tested both (sans printing), AFAIKT there is not more broken than there was before :-) Changes: I have changed a couple of things in the sources of GRX 2.4.5: * src/vdriver/vd_win32.c: - Removed WinMain() and GRXLocalMain() - Moved the window registering code into detect() - Added code in setmode() that creates a message dispatcher thread that creates the graphics window and dispatches messages for it. - Added the WndThread - Changed WndProc(): No more need to Suspend the Worker task and having the Dialog box * include/grx20.h - Nearly the patches Mariano proposed. If __CYGWIN32__ is defined, we also define __WIN32__. I am not sure this is a very good idea in the long run, one should rather check in the code if __MINGW32__ or __CYGWIN32__ is defined. - Removed the #undef GRXMain for the MinGW case, no longer needed. here are the diffs: <<grx20.diff>> <<vd_win32.diff>> There seems to be an issue with the screen clearing after closing and re-opening the graphics window, so this is for sure not the final word. Also, the logic when to give the focus to the graphics window seems not to work as I want it to, so I need to recheck this. Ciao Tom > -----Original Message----- > From: Mariano Alvarez Fernandez [SMTP:malfer@telefonica.net] > Sent: Mittwoch, 22. Januar 2003 19:29 > To: Demmer, Thomas > Cc: 'grx(a)gnu.de' > Subject: Re: GRX2.4.5 and MinGW/Cygwin [Demmer, Thomas] [...] > Please post your modified video driver here, if it doesn't hurt the > Mingw port it will be ok, or (not desirable) we can have a special > version for Mingw. > > > This was easy enough to do by creating grx.dll instead of libgrx.a and > > do the initialization in DllMain(). Thinking about this, I see no point > why > > this cannot be moved to frame buffer creation stage... > > Hmm, I'll have a look into that. > > > > You seem to know well the Windows platform and the GRX Win32 video & > framedrivers have lot of problems/bugs. So you are welcome to improve > it. As a suggestion (I have in my to do list for some day), the best > thing will be to catch the window memory address and let the standard > GRX framedrivers do the work. > > A question about CygWin I'm not sure is license. I think CygWin programs > must be GPL and GRX is LGPL. I don't know if this is a problem. > > Greetings, M.Alvarez

3 2

Re: GRX2.4.5 and MinGW/Cygwin
by Demmer, Thomas 22 Jan '03

22 Jan '03

The advantage of a native port would be that cygwin comes with libtiff, libjpeg and libpng. Anyway, my problem was that MinGW defines __WIN32__, whereas cygwin defines _CYGWIN32__. So I had no framedriver in ftable.c :-( I am not sure if this fixes all issues, because I also changed vd_win32.c to not create the thread calling GRXMain, but rather create a thread that creates the graphics window and dispatches the messages. This was easy enough to do by creating grx.dll instead of libgrx.a and do the initialization in DllMain(). Thinking about this, I see no point why this cannot be moved to frame buffer creation stage... Hmm, I'll have a look into that. Ciao Tom PS: Sorry for responding a bit late, I was not subscribed to the mailing list. From: Mariano Alvarez Fernandez Subject: GRX2.4.5 and MinGW/Cygwin Date: 15 Jan 2003, 22:50:51 Demmer, Thomas wrote: > Hi all, > I have managed to compile GRX under Cygwin with gcc -mno-cygwin > (this is essentially just using MinGW and MinGW-Runtime). > gcc is version 3.2, just for the record. After some minor changes, > it also compiles and links without warnings as a native cygwin > application. It just doesn't run and hangs somewhere in > GrSetMode(). Can anybody enlighten me what is > missing to complete the port to native Cygwin? > Sorry, I don't know how to use Cygwin. But, what advantages would have a native cygwin port? Thomas Demmer Kraft Foods R&D Munich Phone: +49 89 62738-6302 Fax: +49 89 62738-86302 Thought of the Day: Conscience is the inner voice that warns us somebody is looking -- H. L. Mencken

3 2

← Newer
1
...
22
23
24
25
26
27
28
...
56
Older →

Jump to page:

2025

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