Patches / a proposal for the mystic DIB engine

[Felix Nawothnig]

Alexandre Julliard wrote:
>> 2. Export LockDIBSection/Unlock to gdi32.
>>
>>    Adding more exports is not nice but there really is no way around
>>    that, right?
> No, LockDIBSection is a driver internal detail, gdi32 has no business
> knowing about this.

In my code the call to LockDIBSection serves two purposes: to lock the 
DIB section (duh) and to query whether we are in AppMod or GdiMod. The 
former could be done by triggering an exception and letting the driver 
catch it that but I'd think that's rather expensive.

The latter can't be done at all if this is an "driver internal detail" 
so we'd have to always use the DIBDRV implementation when it is there.

This would most likely mean some pretty serious performance regressions 
until we implemented all used functions (in which case we could say the 
export is only temporary).

Since we'll at some point probably have all functions implemented the 
DIB code in the driver will be dead code and it would have to be removed 
anyway. So I don't see the point of trying to keep a hack clean.

Any another issue: There are cases where we really want to have the GDI 
operation be done server-side, regardless of whether we have a 
client-side implementation or not 
(http://www.winehq.com/pipermail/wine-devel/2007-February/053993.html - 
I'd agree with that).

So I really think we need that export.

>> 3. Move dc->funcs to dc->physDev->funcs. Many changes but mostly
>>    mechanical work.
>>
>>    Rationale: This really belongs there. And I need it. :)
> No it doesn't, physDev is an opaque structure as far as gdi32 is
> concerned. Data needed by gdi32 belongs in the DC structure.

Well, yes, it's an opaque structure. With the function pointers added to 
physDev it would no longer be an opaque structure. So?

We'd add a pointer to physDev pointing to an opaque structure of course.

My point is that the addresses of the driver functions are not "data 
needed by gdi32" in the strictest sense. Those addresses are defined by 
the driver and the functions live in the driver, so I think it makes 
sense if the driver would initialize the table, not gdi32. Doing this by 
GetProcAddress() in gdi32/driver.c is not a very clean design. Really.

> You certainly don't want to store the full function table in the
> BITMAPOBJ, it will be the same for all bitmaps. All you need is one

Will it be the same? I'm not sure if there are situations where an 
application has multiple drivers providing memory DCs loaded.

> function table for the DIB driver and one for the normal graphics
> driver.  Forwarding to the graphics driver can be done privately in
> the DIB driver, gdi32 doesn't need to know about it. And you probably

Yes, it's possible. But we'd probably have to write a wrapper for every 
GDI operation. Wouldn't be hard - but it's a lot of code which can be 
easily avoided by just 10 lines outside of dibdrv (in gdi32/bitmap.c). I 
don't really see the point.

> want a separate physDev pointer for it, you'll need to maintain state
> for DIBs too.

Well, we have a couple of DIB-dependent members in BITMAPOBJ - I'd put a 
pointer to this state there. I admit this isn't really clean though.

Felix