Reece Dunn ha scritto:
2009/4/28 Massimo Del Fedele max@veneto.com:
My personal final thoughts....
- 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.
- 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.
- 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