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.
Not sure if someone ever attempted 2) but IMHO it would place DIB handling where it conceptually should be. The dibdrv function array could be added as extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches.
Possible problems I could see are however synchronizing with X (not sure if that is really a possible problem as I do not understand X so far) and maybe other drivers such as wine3d3.drv that seem to hook into winex11.drv too (not sure if for DIB related operations). This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too.
I would like to hear comments of anyone that could add something to this and maybe we can then add the result to the wiki page for further reference.
As it is now Wiki mostly says it is rather desirable, sort of hard to do and the hardest part would be getting it into Wine at all. Maybe if there is a more clear picture as to how it could be done and what is likely to have a chance to pass Alexandre's critical eyes, there would be a bigger chance of someone trying to get it finally started the right way.
Rolf Kalbermatter
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.
- Like in the Transgaming patch hook into winex11.drv where apropriate.
- 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.
bye michael
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.
- 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
Ken Thomases wrote:
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.
I suggested to do all the work server-side a while back:
http://www.winehq.org/pipermail/wine-devel/2005-July/038695.html
Especially see:
http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html
Now, in my opinion we shouldn't care about those apps but it's not up to me. :)
Felix
Felix Nawothnig wrote:
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.
I suggested to do all the work server-side a while back:
Uhm, dunno where I just got the idea that Quartz would feature network transparency. Just ignore me. I really need some coffee now.
On 2/9/07, Rolf Kalbermatter r.kalbermatter@hccnet.nl 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.
Look at bug 3902 (and 421) for some more ideas.
An optimization was suggested to reduce the size of the data copied between wine and the X server, where an invalid rectangle is set/cleared by each drawing function and only the contents of that rectangle (if any) are copied, instead of the entire bitmap. It's not hard to do, but it isn't an overnight thing either - each and every drawing function has to be patched to do this for it to work, and there is a several dozen. Preliminary tests showed some improvements using this approach. And it would still help even if we had a DIB engine, because the volume of data copied would still be lower.
My client-side DIB copy patch from bug 3902 was accepted into wine a few versions back, and it already makes a huge difference for some applications and games.
- Like in the Transgaming patch hook into winex11.drv where apropriate.
- 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.
Not sure if someone ever attempted 2) but IMHO it would place DIB handling where it conceptually should be. The dibdrv function array could be added as extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches.
Possible problems I could see are however synchronizing with X (not sure if that is really a possible problem as I do not understand X so far) and maybe other drivers such as wine3d3.drv that seem to hook into winex11.drv too (not sure if for DIB related operations).
X synchronization is done in winex11.drv. Calling X11DRV_LockDIBSection returns where the DIB is, and if it is client-side, you just draw to it by accessing memory - otherwise you draw by using equivalent xlib functions.
It would be pointless and extremely difficult making a dibdrv - just patch winex11.drv; dibdrv would need access to many internal X11DRV_ functions.
This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too.
I would like to hear comments of anyone that could add something to this and maybe we can then add the result to the wiki page for further reference.
As it is now Wiki mostly says it is rather desirable, sort of hard to do and the hardest part would be getting it into Wine at all. Maybe if there is a more clear picture as to how it could be done and what is likely to have a chance to pass Alexandre's critical eyes, there would be a bigger chance of someone trying to get it finally started the right way.
The hard part is not the X11 stuff, it is writing drawing algorithms that not only draw in all of 1, 4, 8, 16, 24, and 32 bit colour-depth and are pixel-for-pixel equivalent with the way Windows does them, but the dozens of little things like patterns, brushes, raster ops, custom region clipping, and others which affect each other and almost everything else, making the implementation of a client-side DIB engine a real PITA.
Rolf Kalbermatter
Damjan Jovanovic
On Fr, 2007-02-09 at 11:41 +0100, Rolf Kalbermatter wrote:
- Like in the Transgaming patch hook into winex11.drv where apropriate.
- Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already.
extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches.
I suggest option 2), but without the need of a Display-Driver at all as the long-term target. The API for that Engine is exported by GDI32 ("Eng*" ) and when we implement that, we can reuse the API for more drivers (OpenGL, VNC, RDP, SDL, Printer-Drivers ...) The API-declaration for "Eng*" is in "ddk/winddi.h"
A line from the current wine GDI-Engine as Example: ("LineTo" from dlls/gdi32/painting.c): ---- cut ----
ret = dc->funcs->pLineTo && dc->funcs->pLineTo(dc->physDev,x,y);
---- cut ----
We simple call the Driver, and when the Driver does not support that painting-function, the API failed. On windows, gdi32.dll and the Driver can fallback at any time to "Eng*" ("EngLineTo" in the Example) and the drawing is split in more primitive API-calls whith setting a single pixel at the end. (You can think of a Driver, that implement "LineTo" only for horizontal and vertical lines and fallback to "EngLineTo" for diagonal lines)
So instead of implementing a full DIB-Engine in a dibdrv, we should split the implementation in a logical part ("Eng*" API) and a drawing part.
Possible problems I could see are however synchronizing with X (not sure if
I have no Idea, what is needed here.
This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too.
When we use "Eng*", it's there for all drivers and is the same API as in windows.
Thanks for looking at the dib-issue
-
Damjan Jovanovic -
Detlef Riekenberg -
Felix Nawothnig -
Ken Thomases -
Michael Stefaniuc -
Rolf Kalbermatter