Tackling gdiplus?

[Rolf Kalbermatter]

Huw Davies [mailto:huw at 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