On Feb 9, 2007, at 5:18 AM, Michael Stefaniuc wrote:
Rolf Kalbermatter wrote:
I have been following this discussion for quite some time and finally
decided to look into it a little bit. While the Wiki mentions that a
difficult part of this would be to get any design accepted by
Alexandre it
does absolutely not say in any way what kind of approach would be
likely to
be accepted, other than it needs to be in small incremental steps.
I must admit that I haven't entirely looked through the whole Wine
tree yet
so I might be missing something but from the old Transgaming patch
and some
investigation into GDI32 I would see two principal aproaches to
add such an
interface to Wine.
1) Like in the Transgaming patch hook into winex11.drv where
apropriate.
2) Add the dib engine as a dibdrv into GDI32 directly similar to
what has
been done for enhmfdrv and mfdrv already.
Obviously 1) has been tried and seemed to work in some ways
eventhough there
would still need to be quite some more work to be done. What I
don't like
about this aproach is that conceptually it seems to add this
functionality
at the wrong end. If there is ever going to be another display
driver than
winex11.drv all the hooking would have to be done again and also
adding new
GDI methods to the driver as development goes always requires also
some
significant changes to winex11.drv.
There is already an other display driver: winequartz.drv for MacOS.
And
Pierre is working to move code out of winex11.drv and into the GDI and
User dlls to not have to duplicate it again in winequartz.drv.
Pierre could speak to this better than I, but my understanding is
that the Quartz driver does not need the DIB engine. Quartz (the
Mac's imaging and windowing API) is capable of drawing to offscreen
bitmaps directly, at color depths that need not match the display's.
This has implications for the design of the DIB engine, because it
should be designed to allow the graphics driver to override/bypass it.
-Ken
