DIB clarification

Jeff Cook jeff at deserettechnology.com
Sun Aug 29 07:18:52 CDT 2010


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



More information about the wine-devel mailing list