See comments below, let's see how Outlook
ruins the format this time :-)
> -----Original Message-----
> From: Josu Onandia [SMTP:jonandia@fagorautomation.es]
> Sent: Mittwoch, 5. Februar 2003 18:04
> To: Demmer, Thomas
> Cc: 'GRX Mailing List'
> Subject: RE: GrBitBlt is slow, MinGW32
>
> 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 have not yet checked those, but we have to start somewhere...
> I think you are right in your second solution, but I have some questions:
>
> - Why a DeviceIndependentBitmap? What advantages has over a
> CompatibleBitmap?
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.
> - Why do you need synchronization between threads? Aren't they already
> synchronized?
I noticed some interesting and hard to reproduce glitches in updating
the graphics window when it was partly overlapped and the overlapping
window was removed during WM_PAINT and the main thread kept on
painting or so... I think this is the relevant part of the Win SDK help that
explains
it:
Windows NT: You need to guarantee that the GDI subsystem has completed any
drawing to a bitmap created by CreateDIBSection before you draw to the
bitmap yourself. Access to the bitmap must be synchronized. Do this by
calling the GdiFlush function. This applies to any use of the pointer to the
bitmap's bit values, including passing the pointer in calls to functions
such as SetDIBits.
Anyway, I added an event where the updating task signals the main task when
the screen update is done. On my desktop a 800x600x24bpp BitBlt from Ram to
Video takes
approx. 36ms, my Laptop is a bit slower, there it takes approx 70ms (Plain
SRCCPY),
I found some interesting macros in src/include/memcopy.h, but found no
explanations for them. Can anybody enlighten me?
> - 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?
>
It ain't me babe, Bob Dylan :-)
> 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
