DIB Engine : passing all tests

[Massimo Del Fedele]

Alexandre Julliard ha scritto:
> 
> Well, the prototype doesn't show much evidence of a good design. Maybe
> Massimo has one in mind, but he hasn't explained it so far.
> 

Well, I still think that the "goodness" of a design is a matter of taste.
My design is *a* design, started because of a personal need and evoluted
by *my* personal taste, which was the only way I had without proper roadmap.

Btw, I thought to have explained enough the reasons of the choosen design,
but I may be wrong.... so I'll put again here the pursued goals :

1) Something usable. That means something that don't work "just for a couple
of apps" but that work in general at least as current driver do.
This goal il about 90% to be reached, imho. It'll be 100% in a couple of
monthes, if my job will let me enough spare time.

2) Something optional. There's no point, imo, to make a driver that breaks
even just one app without the ability to fall back to original gdi32/winex11.
Goal 100% reached.

3) Provide a working engine that allow in deep testing of speed difference.
We know that *some* apps do benefit of it (again, autocad speed gain on TT
fonts is something like 50x - 100x), but I've seen that recent thoughts were
those of a limited speed gain.... Well, I think that many important apps could
benefit of it. Goal 80% reached, as mixed blitting is something slower than
original driver. No simple way to make it as fast without touching winex11.drv.

4) "prepare the road" to a definitive migration to what I think should be the
"right final design", so DIBs handled by gdi32 double buffered by DDB inside
winex11.drv; mixed blitting done inside winex11. I think that one would be the
only viable way if we want blitting speed *and* DIB drawing speed.
My driver is doing the needed separation of 2 processes. Once completed, moving
them into gdi32/winex11.drv should be quite easy and could be done stepwise.

5) for fun. Ops, that one should be the n. 1 :-)

About point 4, which, I guess, is the most important for you, the next step would be
to make a winex11-2.drv on which DIB processing would be stripped away, and with
added DDB buffering of DIBs and mixed blit operations.
That driver could be connected to (and tested with) winedib.drv, always as an option
in registry/environment.
Once ready and stable enough it should be made permanently enabled and remaining part of
winedib.drv could be merged inside gdi32; that could also be made stepwise.
Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least
if we don't want to change something in driver function tables.... which would be the
best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor
I think to do it for the moment).
A simple GetLine() * PutLine() that do translation between 32 bit RGBA <--> DDB inside
winex11.drv and callable by gdi32 would of course avoid all code duplication needed for
mixed blitting, keeping needed speed. That addition would be trivial.

I think my design has some advantages and some disadvantages to other ones, but it's
superior to the "double pointer approach" taken before, for reasons already explained.
The main "disadvantage", maybe the only one, is to have for some time 2 different
drivers in wine..... but OTOH it allows deep testing without breaking anything.

I hope I explained enough about it. Technical details are in (maybe too abundants...) code
comments.

Ciao

Max