Jesse Allen ha scritto:
I'm trying to understand what the problem is to make you think there needs to be a change. Are most of the problems with Blt related functions?
No
It is my understanding the DIB engine should actually be able to call the display driver and vice-versa. So I think we shouldn't abandon the two driver approach, just add the capability to call each other. I believe GDI on windows has infrastructure for this too.
As I said before, I firmly think that the DIB engine belongs to GDI and *not* to an external driver. That said, I was told that the "right" approach would have been : 1) a gradual introduction of the engine inside wine. 2) it shouldn't break anything on the way 3) it should be done in small patches I guess you've seen too, developing your engine, that all those requirement are impossible to meet at once. DIBs are by now too tightly integrated inside X11. The 2 driver approach was a compromise and, trying to use it, I have seen that it was cumbersome to maintain and very error prone. You have 2 DC function pointers, 2 DC physical devices and, the really bad stuff, the function pointers inside the bitmap structure that should be kept in sync with the DC ones. Even more, gdi code use bitmap function pointers to tell to which kind of DC belongs the bitmap. The SetOwnerDC() along needed to be patched because of that, and it wasn't enough, still. You can look at my previous code.... many, many small hacks here and there just to be sure that all pointers were kept in sync. The bitblt stuff was one of the easier part.... you can also see it in my new code, it's completely working now, beside the pattern blitting that need some more work. Then I thought.... all that stuff for what ? Just to have a compromise engine semi-embedded into gdi32 ? An engine that, to make it "right" would mean another almost full gdi and x11 rewrite ? An engine on which every small unrelated change in gdi32 could bring nasty bugs on the engine code ? And a stuff that had to be manually rebased on each change inside gdi32, hopelessly waiting to see it embedded in wine main tree ? No, thanx. The "right" way to do it would be, in my humble opinion, to "fork" X11 and gdi32 parts and to rewrite them moving all dib processing from x11 to gdi32, besides keeping, maybe, a pixmap copy of dib inside X11. But even being (maybe) able to do it, I guess that almost nobody would take the job without being sure that it will enter into main three some day.... at least, not me :-) So, mostly because I *need* the engine for my job, and because I was tired of manual rebasing stuff, and, last but not least, because I think it's the only viable way to prepare the stuff for the "right" migration of DIB inside gdi, I rewrote it with new approach. Advantages : 1) Almost no changes, by now, to gdi32 code nor to X11 code. The "almost" could also be "none at all", if wished. Just insert "winedib.drv" on registry driver's names and the job is done. I did put the small drive load patch on gdi32 because I wanted it working without fiddling with the registry, and it's about 5 patched lines and a some 30 lines added. No more no less. No more hassles to maintain it on each git release. 2) It can't, by design, break anything. If disabled, it's just as it wouldn't exist. 3) Once setup and tested, it can be a good starting point to do the "right" approach, so to move DIB X11 code inside gdi32. When you have all DIB code inside winedib.drv, you could then, really step-by-step add some X11 optimizations and then move DIB code inside gdi32. When finished, the temporary winedib.drv would simply disappear. I can tell you, it took me more than 2 months to make it "almost working" with the 2 driver approach, and a whole couple of days (!!!) to make it *fully* working with the new approach.... and much more stable. Ciao Max
