Hi Jeff,
this has in fact come up before, and been addressed. The main problem with the current attempt, as far as I know, is that the risk of regressions is so high that only very high quality changes stand any chance of getting accepted. In the case of a DIB engine, the attempts have usually required accepting a large piece of new code wholesale, with a promise of future fixes. This is a very risky way to make a change, and Alexandre has repeatedly shown his preference for small, incremental changes wherever possible.
Without knowing the area in depth, I can only offer this commentary on Massimo's work: Massimo doesn't have a proven track record in the community, so I personally wouldn't trust his ability to minimize regressions, or to maintain his code until regressions he's caused have been fixed. This is nothing to do with him personally, I'd have the same expectations of any relatively new contributor.
As to the first, minimizing regressions, this is something a new developer can address by testing an area thoroughly. Often, the best path forward for new code is to introduce substantial new tests in the area before beginning to make functional changes.
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.
If you hate to do it, why do you do it? It's hard to maintain equanimity when you describe CodeWeavers as evil. Even if you do ascribe that to someone else, why on earth do you bother to repeat it? Such a sentiment is so absurd, it could best be accepted as a joke, but a bad one. Think about it: who has contributed the most, in real dollars, to Wine's development over time? Who releases their own Wine tree in source form? Who employs the most Wine contributors? Just because some pissed off slashdotter said something doesn't make it worthy of a second's thought.
Full disclosure: I once did a very small amount of contract work for CodeWeavers, approximately 6 years ago.
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";
Maybe to you, because you're new around here. When has Alexandre ever been long-winded? He's terse here just as he is elsewhere. If there is any single reason to reject a piece of code, that's enough. See e.g. Henri's comment on a patch the other day [1]: when we give negative feedback on a patch here, we usually don't point out every instance of an error, and expect the contributor to generalize from the feedback. Hence negative feedback here is usually terse.
it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it.
You can only hold hostage something that exists. There is no such beast as a working DIB engine.
. 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?
Yes, of course they are. That's a valid reason for rejection of simple patches. Why shouldn't it be for major, high-risk-of-regression patches?
- Write more gdi32 and any other relevant test cases to prove that
the DIB engine is generally well-behaved
Yes, this is certainly needed.
Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed?
This could also help. If I recall correctly, Jeremy White mentioned at Wineconf 2008 that this was a major reason they haven't invested serious energy into one themselves: they had a hard time finding an application that they cared about that benefited significantly from a DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't care about AutoCAD, or whether they hadn't tested with it, or whether my memory is just faulty, I'm not sure.
Hope that helps, --Juan
[1] http://www.winehq.org/pipermail/wine-devel/2010-August/086207.html