On Sun, Aug 29, 2010 at 2:18 PM, Jeff Cook <jeff at 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:
>> 1) 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?
>> 1) 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