Sorry folks, been on a business trip without access to mail :-(

The second call is for keeping the in-memory buffer up to date. One minor speed up would be just to do the call to the memory context, call InvalidateRect() and move the first call to the WindowProc.

By now I have the r2v and v2r running for simply copying from RAM context to screen and back. They are quite fast and I am happy with them. As soon as I understand the fwdcopy_XXX() macros to handle the rest, I'll send a complete patch. Probable timing is next wednesday.

Ciao Tom

-----Original Message----- From: Eike Lange [mailto:eike.lange@uni-essen.de] Sent: Tuesday, February 11, 2003 2:51 PM To: 'GRX Mailing List' Subject: 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