DIB Engine : passing all tests

Massimo Del Fedele max at veneto.com
Tue May 26 05:42:05 CDT 2009

Alexandre Julliard ha scritto:

Hi Alexandre,

> One of the main problems I see is that your design is based on the
> premise that there's only one graphics driver, the X11 driver.

Well, I guess I expressed myself not completely corrected.
My engine do load the winex11 exactly as gdi32 does.
That means that in must not be winex11, it can be any driver that
gdi32 would have loaded. The loading phase is like this :

GDI32  <-- load any driver and gets function pointers for DC and bitmap (ORIGINAL)

GDI32 <-- load winedib.drv <-- load any driver (etcetera) (MY WAY)

The driver loading mechanics is the gdi32 one duplicated in winedib.drv.
winedib.drv just intercept DIB calls and forward others to *any* other
driver. Again, in my thoughts that is a "transient" phase, at the end all
dib processing should go inside gdi32.

> clearly not the case, DIBs can be used with any driver (and with
> multiple drivers at the same time). This is also why you can't have the
> DIB driver decide on when to forward/not forward to the X11 driver, it
> should go in the other direction.
> I'm also very skeptical about mirroring DIBs with a DDB.

Well, that was just a thought. I think that maintaining a mirrored DDB copy
would slow down just a bit drawing operations but would speed up a lot blitting.
But it's not a need.

  But even if you
> do this that should be a purely internal x11drv decision, the DIB engine
> shouldn't have any notion about this at all. This means you can't expose
> DIB->DDB conversion routines, DDBs are entirely up to the graphics
> driver.
I was meaning exposing a "stripped-extended" version of GetDIBits and SetDIBits, allowing
partial image transfers. Again, that's not a need, it will just avoid code duplication
in gdi32 and winex11. That would allow gdi32 to read and write portions of DDB with a call
to winex11.
Like it is now, you need knowledge of different DIB formats both in winex11 AND in gdi32;
having this function would allow to move the "mixed blitting" stuffs almost completely inside
gdi32. That's also just a suggestion.
In my engine I have a bunch of PutLinexxx and GetLinexxx that do conversion from any format
do 32 bit RGBA and vice versa; the functions I spoke about are just extensions of them
for handling DDB conversion to/from 32 bit RGBA, and should reside, of course, in winex11.

I agree with you that the DDB caching of DIBs should be a winex11 stuff and totally transparent
to gdi32.

Thanx for answers


More information about the wine-devel mailing list