Erich Hoover ha scritto:
What I was trying to say is if you could have something like this for all the stubs:
BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT widthDst, INT heightDst, DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT widthSrc, INT heightSrc, BLENDFUNCTION blendfn) { FIXME("reverting to slow behavior!\n"); return TheOldBehavior->AlphaBlend(...); }
While I'm obviously not greatly familiar with this code, it seems like the engine would have a better chance of being successful if unimplemented features fell back to the old behavior. It seems like that would allow you to gradually transition over to the integrated DIB engine a little bit at a time, rather than having a lot of unavailable features that would all need to be implemented before the integrated DIB engine could be turned on for everyone. Even if you had to create a special surface and copy the bitmap back and forth every time you had to revert to the old behavior it seems like it would at least provide a good testbed.
Erich Hoover ehoover@mines.edu mailto:ehoover@mines.edu
Well... almost impossible by keeping GDI and driver structure separated. You call winex11 whith its physDev, and WineDib with it's own (different) physDev. Either don't have knowledge of other's structure (they're opaque pointers), nor they have e pointer of each other. So, from Dib driver is impossible to call an x11 driver function. That could be done directly from inside GDI32, but would require some deep changes on it, which I wanted to avoid. BTW, I'm still thinking that the "better" way of adding the dib engine would be from inside gdi32, but whis would mean to change deeply a code that is working good. Another possibility would be to add a pointer to x11 physDev inside the Dib physDev.... that one would be easier, but hacky.
Ciao
Max