Patches / a proposal for the mystic DIB engine
flexo at holycrap.org
Thu Apr 12 08:12:57 CDT 2007
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
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.
More information about the wine-devel