When a window gets partially or totally obscured or minimized, what you draw on it it's simply lost. When it gets unobscured the library has to repaint it. That's why the driver works with 2 bitmaps: one is the on-screen window and the other is an on-memory bitmap. Both are synchronized. When a part of the window gets visible it receives the message WM_PAINT it simply copies from the in-memory bitmap to the window. Perhaps XWindows makes this operation automatically, I don't know.

But anyway I believe that the BitBlit operation is very fast. The problem in the driver is not the function bitblt, but the functions i_drawbitmap, bltv2r_8, and bltr2v_8, because they have to convert between a GR_frameRAM8 format and the Windows Bitmap format, and they do it one pixel at a time (SetPixel/GetPixel). I think that the suggestion of Thomas about using DeviceIndependentBitmaps is VERY interesting.

Josu

-----Mensaje original----- De: Eike Lange [SMTP:eike.lange@uni-essen.de] Enviado el: martes 11 de febrero de 2003 14:51 Para: 'GRX Mailing List' Asunto: Re: GrBitBlt is slow, MinGW32

Hi!

On Thu, Feb 06, 2003 at 12:48:05PM +0100, Demmer, Thomas wrote:

...

You can easily and quickly write to the RGB values from memory contexts. If there is a way to quickly draw from a memory context to the hardware,

I'd

...

prefer that, but I don't know.

...

I'm still interested in this driver, and I'd like to colaborate, but

I'm

The framedriver for Linux (fd_xwin.c) just uses XCopyArea. The one for win32 (fd_win32.c) uses two BitBlt calls. Could we get rid of one of them? What is the second one for?

Eike