The DIB engine... does anyone know how to get it into Wine?

[Massimo Del Fedele]

Reece Dunn ha scritto:
> 2009/4/28 Massimo Del Fedele <max at veneto.com>:
>> My personal final thoughts....
>>
>> 1) It's obvious (but then, why we're repeating it forever ?) that
>> final result is : DIB inside gdi32 and DDBs inside X11, with
>> probably DIB cached to DDBs in x11 for performance reasons.
> 
> Agreed.
> 
>> 2) Assuming point 1, the *only* problem is to decide how get
>> to it, so choose the best solution.
> 
> There are probably other problems/issues/considerations, but that is
> the big one.
> 
>> 3) the "best" solution depends on zillions of personal factors.
>> Here we say "you can't have full wine bottle and drunken bride".
> 
> I would say that there are a lot of factors (forget the personal part).

Personal part is always there, we're not machines :-)

> 
>> So, can we afford months of regression bugs ? Perfect, just
>> start adding/replacing code to gdi32 AND winex11.drv and it's
>> all ok. But then I guess I'll stay with wine-1.1.20 forever,
>> resorting to wine-1.1.5 when I need something that
>> mshtml regressions broke...
> 
> The rationale behind small incremental changes is that it makes it
> easier to bisect. If there is one big bang patch, and there are a
> hundred regressions, it is harder to identify where they are. Also,
> smaller patches make it easier to review and to verify correct.
> 
I agree, *when* it is possible.
The question is..... it is ?

>> We can't afford that ? so there's no other way than fork
>> display driver and let people who needs it to test the
>> new one up it becomes stable enough to replace the old one.
>>
>> I guess we could speak about it for years, but I really don't see
>> another path that the 2 above. And, btw, I still don't know which
>> would be the preferred one. The rest are simple implementation
>> details.
> 
> The two things to get right are (1) the correct architecture and (2)
> an incremental migration strategy (i.e. a way to incrementally
> refactor the existing code to the new "DIB engine/support" code). Look
> at what is being done for the Direct3D 10 implementation, for example.

I'd agree with you, if I'd see a way to do it incrementally without
forking driver and without breaking the whole.
I didn't look at Direct3d 10, but I guess he don't affect zillions
of apps, does it ? DX10 <--> Vista, and (AFAIK) most DX apps still use
9. Touching at gdi32 would break almost 100% of running apps if someting
goes wrong.

> 
> Another benefit to the small incremental, always functional approach
> is that the code will be tested by everyone who uses Wine and not just
> people who are testing the side-line patches.
> 
I'd agree again, *if* there is a way to do it incrementally.
Sorry but I don't see any.
You can't, for example, say "ok, let's fix line drawings routines, from
now they'll be done from gdi32, and don't touch the rest, because of the
way DIB are tied to X11 pixmaps.
For line routines, for example, you must, *at once* :
1) patch the gdi32 part, to draw directly on dib
2) patch the x11 part to avoid current convert-modify-draw-convert
    stuff that is done now.... and *just* for line routines, if you don't
    want to touch at rest.
3) all above should be done for each DIB format, so you have to multiply
    the stuff by 8
4) probably check the polyline and other drawing stuffs that may use parts
    of line drawing. Don't forget rectangle filling, pattern drawing.....

If you don't do 1+2+3+4 at once you'll have a regression. Even if you do
you can, if something strange happens. Again, mshtml is a good example....

Nor can you take DIB away from X11 without patching the whole gdi32, or
rewriting the whole X11 drv or both.
There's no single routine in X11 that can be split/patched alone without
affecting the whole, imho.
Even just the "2 drivers approach" meant an handful of sparse hacks on
many gdi32 routines.... and it was a "simple" approach.

> The DIB engine is a huge undertaking. It is probably several years
> worth of effort to get right and requires a lot of knowledge to get
> right (both of Windows and Wine).
> 
Here I don't agree. My engine is far from being perfect nor complete, and I'm
surely not a gdi nor an x11 guru. Not even a programmer... My job is
civil ingeneering. Nor I'm an extraterrestrial :-)
But it works good enough for many apps. It's just a collection of
well known snippets and algorithms and the result of some days of
googling for documentation.
I just made it to have AutoCAD usable and it does, speeding it up
often 100:1. I think it would require a couple of months to complete
with enough testers, an another month to optimize a bit.
One year or something more of my spare time.
Once completed, the stripping/modifying of DIB code in X11 would be
quite straightforward.
Then, and only then, the engine could be embedded in small patches
inside inside gdi32.... just move the code from winedib.drv, routine
by routine, making the winedib one just a forward call to the new X11
for the caching part.

BTW, that's just my personal opinion, of course :-)

Ciao

Max