Re: GrBitBlt is slow, MinGW32

Josu Onandia wrote:

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?

If we have a pointer to the memory draw area we don't need any new framedriver, the standard GRX framedrivers can do the work (like in the linux framebuffer version).