Huw Davies [mailto:huw@codeweavers.com] wrote:
It seems to me that gdiplus is a great project for an intern; it's scalable and not 'all or nothing' unlike the dib engine.
In looking at the DIB engine I feel that one of the biggest obstacles to get it done is integrating it in a way that it can be partially integrated piece by piece without requiring a huge amount of patches that needs to be applied more or less in one go in order to still have it all work.
On the other hand I think that is the only way to get it in at all unless Alexandre himself is going to do it and if you do it that way I would think it is not really an all or nothing thing. You can start with addition of infrastructure in the display driver interface without really changing anything in the actual handling.
Once the necessary support to the display driver interface is done the DIB engine could be implemented and integrated piece by piece such as first Put/GetPixel operations and then lines, and so on. This means that the X server synchronization would have to remain in the X11 driver until every function is implemented but it could reduce the requirement to synchronize every time as DIB engine support for a new operation is added, although some operations won't have a lot of effect for most applications. I'm still convinced that the best aproach to integrate a DIB engine is inside GDI and not in the display driver. Not so much because it is easier (it seems not to be) but because it is cleaner and in the long run will benefit other possible display drivers too, without having to be concerned in such a driver about DIB operations if one doesn't really want to.
I think likely candidates to have speed effects are Get/PutPixel, LineTo, and the various BitBlt operations, with the last ones probably being also the most complex ones. More esoteric operations such as Arcs will eventually have to be implemented too somehow but wouldn't be the most important ones to start with.
Rolf Kalbermatter