[cairo] Cairo and WinCe image drawing

[Owen Taylor]

On Wed, 2006-04-12 at 11:39 +0200, Stefan Klug wrote:
> Hi everybody,
> 
> first big thanks and keep up the great work to all cairo developers...
> 
> I'm currently developing a WinCe application with heavy graphic usage in 
> fullscreen mode.
> I'd like to get away from my old graphic engine and port everything to 
> cairo to stay as platform independent as possible.
> 
> Compiling Cairo for WinCe works after some modifications mainly to the 
> win32 surface. Font rendering is still on my ToDo list.
> 
> The problem is, that it's rather slow.
> (Dragging a fullscreen image should be possible at 24fps but I get 
> around 5fps (no exact measurement))
> I'm only drawing untransformed images at integer positions.
> The main bottleneck seems to be the transfer of imagedata to the target 
> surface.
> As cairo internally only works with 4 bytes per pixel (even in RGB24 
> mode as far as I can see) the amount of memory to transfer is rather big 
> for a ARM powered CE Device.
> Wouldn't it be possible to introduce a CAIRO_FORMAT_RGB16_565 format? 
> This could greatly improve speed for image drawing on most of the WinCe 
> devices out there as the frame buffer uses 2bytes per pixel.
> I think the image drawing functions wouldn't be a big problem as pixman 
> already supports these formats. But I don't have any knowledge about the 
> internals of the path rasterization functions.
> 
> Or did I completely miss some something.

I think the first thing to figure out is what code paths you are going
through - this depends on what operations you are doing, whether you
are drawing to a DIB or DDB, and so forth.

If you have profiling tools available, the simplest thing to do may
be to dig those out and profile your app and see where the time
is being spent.

If not, and you have a debugger available that can run the code at
full speed, and interrupt it at your command, just interrupting the
code a few dozen times can give you a good sense of where it is
spending time.

Failing that, reading the code carefully or tracing through it
can give you a sense of how your operations will be handled.

My gut feeling is that I don't think that storing the source image
internally in memory as 32-bit xRGB is going to have any significant
effect on performance .. it might *possibly* trigger slow paths
in drawing, but drawing 32-bit source images to 16 bit destinations
is not a rare operation and is likely to be optimized. Memory 
bandwidth from reading from the source is unlikely to be an issue
in any case.

Regards,
						Owen