Roderick Colenbrander ha scritto:
No then you don't have the engine yet. In my proposal you would first make winex11.drv not depend on DIBs (the conversion code would still be in winex11.drv),
uhmmm... and in the meanwhile where would be DIB processed ?
then you move the conversion code over (you would
still perform 8bit drawing using X by converting it to 24bit but this conversion would be done inside gdi32).
That means taking a DIB, converting to a pixmap, send through x11, draw it, get it back from x11 and reconvert from inside gdi ? I guess you're replicating the "bad" behaviour of x11 driver just moving it to gdi32 and adding even more overhead....
In the third step you would
add software based drawing functions, so the actual DIB engine.
Roderick
It wouldn't be simpler just start with DIB code, let X11 manage a pixmap copy of DIB, so replicating the drawings via software from inside gdi32 AND with X11 on the replicated copy inside it ? I guess that one should be the final result... Why all these intermediate steps which btw don't bring any advantage ?
I still see the behaviour simpler : 1) Make DIB code draw to DIBS, forward to X11 the rest. From gdi32 or from winedib.drv it's just a matter of taste.... former would be definitive solution, latter would allow deep testing without breaking anything. To see the former way, just look at mshtml code and its associated regressions..... 2) fork winex11.drv, putting inside all non-drawing and DDB stuffs from old winex11 and add brand new DIB<->DDB cached pixmap handling 3) when 2 is ready, jsut replace old winex11 with new one; if you choose the first way on step 1 you're ready, if you've chosen the second way,migrate winedib.drv code into gdi32.
No regressions, no hassles, progressive and clean.
Max