Alexandre Julliard wrote:
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.
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