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@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:
- 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.
- 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@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