On Sun, Aug 29, 2010 at 2:18 PM, Jeff Cook jeff@deserettechnology.com wrote:
I hate to stir the pot, especially as an unknown in the community, but I've spent the last few hours reading WINE's history regarding DIB engines and it is pretty distressing.
I have seen expressions of frustration from many regarding the handling of the mostly-functional DIB engine that Massimo wrote. AJ's terseness on the issue is puzzling. I find it really weird that such a major and long-standing thing would just be left to languish without any detailed reasons. Though I do not believe it, you can start to see why the slashdotter described Codeweavers' corporate agenda as "evil"; it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it. This wouldn't be a problem of course if it appeared that Alexandre was willing to work with external developers on the DIB engine, but he has given very sparse criticism.
Should we all just accept that Massimo's engine is yet another DIB engine gone to waste and there is no future hope for it at all? Max's statements to that effect can be confusing out of context because of his non-native English, but everything I have seen indicates that he is totally willing to work on upstream merging if Alexandre is willing to cooperate. All cases of saying "it won't get merged" etc. by Max seem to reference AJ's reluctance to provide useful criticism on the code that gets posted.
It is not my intention to start another huge flamewar or thread on the matter. I just want to promote a reliable roadmap and help resolve this -- it seems like a total shame that there have been multiple DIB engines written and no parts of any of them were deemed worthy of inclusion in WINE. Max at least has indicated a desire to modify the code as necessary if a useful road map or ideation were provided, so why is it so hard to get the road map? Alexandre is right that the architecture is a lot of work, but I am not asking for him to write out a complete spec, and I don't think the community is, either; the main thing, as far as I can tell, is that the interaction and feedback on a major step forward for WINE has been minimal.
People are still reporting major speedups on bug #421 so I don't think this is a lost cause unworthy of effort as some suggest.
The most feedback I was able to find from Alexandre was on May 2009's DIB engine passing all tests thread at http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 . Alexandre's single major standing complaints seem to be a lack of test cases and Massimo not establishing a good record with simple patches. Are those still valid reasons?
The complaint regarding driver loading was addressed, but it sounds like Alexandre wants it in the opposite direction (forwarding calls from winex11.drv (or whatever driver) to winedib.drv instead of the other way around). Is that a very serious problem?
So, if we can, let's get a few points down on what needs to be modified for DIB to make it into WINE, even as an experimental branch:
- Write more gdi32 and any other relevant test cases to prove that
the DIB engine is generally well-behaved 2) Reverse the DIB ordering and call winedib.drv only as needed, instead of passing everything through winedib.drv first. 3) ?
Or, in the case that Max's DIB is gone forever and is considered irreparable, why don't we discuss what's needed for a different DIB engine?
- Write more gdi32 and any other relevant test cases to prove that
the DIB engine is generally well-behaved 2) Works well with any wine display driver. (already in Max's code) 3) Applied and developed cooperatively and incrementally with the WINE community 4) Easily disabled / non-disruptive (already in Max's code) 5) ? What else needs to go here?
Is this accurate?
Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed?
Thanks for reading. From Jeff
Let me give my stance on the DIB engine but before I do that lets give a rough summary what the DIB engine is about because not everyone has a good idea what it is, some people think it is something magical.
A DIB(Section) is a type of surface you can draw to using GDI calls but you can also directly mess with its bits. On Windows DIB rendering is all done in software ('using the DIB engine'). In Wine we cheat by delegating most of the work to X11. This causes various challenges and some cause performance issues (though various of them are fixable even without a DIB engine).
Two of the challenges: - A copy of the DIB exists on the X-server and in system memory and both copies have to be synced. You don't always want to have them in sync (it might cause unneeded x11->sysmem copies). The syncing is done using memory protection tricks. If the system memory copy is not up to date, a segmentation fault is triggered on access to the bits and during that time the DIB is copied back from the X-server. This causes an issue for some bad applications which directly mess with the stack pointer while they are playing with the DIB.
- Depth conversion. When the DIB is at a different color depth (lets say it is 8-bit) than the X-server, the DIB is first converted to the depth of the X-server and afterwards it is converted back. Depending on the color depth this can be a heavy operation (various old games like Age of Empires are quite slow due to this). This used to be a big problem but due to XRender work for Wine, the conversion is not needed anymore for 16-bit/24-bit/32-bit DIBSections. It is still an issue for 8-bit and some other depths but for a big part it can be fixed (Alexandre also said it is more correct if a DIB is 8-bit, to just pass it as 8-bit to X).
Do we really need a DIB engine? For a part, 'time' has made the need for a DIB engine less important. Systems have become faster, X11 has become faster, XRender has helped and so on. There are applications which can really profit from a DIB engine but some of them can be made happy by improving the current code (e.g. don't perform color conversion and let X11 work at the depth of the DIB).
Personally I think the requirements for a DIB engine have changed and if we add one it should be part of a big Wine 2D rendering rewrite. In previous threads about a Wine quartz/cocoa driver, I mentioned that in Vista/Win7 Microsoft drastically changed their 2D engine and I think we should do something similar. The best way to summarize the changes is that their 'DIB engine' takes care of most tasks of the 'DDB engine'. Except for some common BitBlt ROPs, color filling, font rendering and a few other operations (this are the same calls Cairo/Cocoa/XRender supports) EVERYTHING is software rendered.
If we would go the Vista/Win7 way, the DIB engine would be something different from the previously proposed ones. We would move most of our rendering to the shared DIB/DDB engine. The few hw accelerated DDB operations could be implemented using OpenGL/XRender or it could even make sense to use Direct3D. The winex11 driver would implement these DDB options, would handle window management and input. Further it would be a lot easier to write a Cocoa driver for Mac.
I'm not sure if we will make such drastic changes at all. It would be a huge project (at least 1 year but likely more) of work.
Roderick