[cairo] WinXp benchmarks

[Owen Taylor]

Oleg Smolsky wrote:
> Hi all,
> 
> I've just done a few benchmarks drawing a gauge (a dial with a needle
> and a few digits) into a cairo surface attached to DCs of various
> sizes. Here are the results:
> 
> 200x200 DC:     6ms  per frame
> 300x300 DC:     9ms  per frame
> 400x400 DC:     15ms per frame
> 500x500 DC:     24ms per frame
> 600x600 DC:     31ms per frame
> 700x700 DC:     41ms per frame
> 800x800 DC:     52ms per frame
> 900x900 DC:     65ms per frame
> 
> It's easy to see that when the square edge grows linearly, both the
> pixel count and rendering time grow exponentially.

Do you mean quadratically? The timings above are actually going up
*slower* than the pixel count.

(65ms. / 6ms. is approximately a factor of 11. 900x900 / 200x200 is
  approximately a factor of 20.) Which sounds reasonable ... a mix of
linear and quadratic components is what I'd expect. The overall
time isn't that good, of course...

> BTW this test is done by attaching cairo to DCs of varying size and
> drawing lots of frames as quickly as possible. Ie my cairo_*() calls
> do not change, but the viewable output keeps getting bigger. In other
> words, cairo keeps rendering more and more pixels.
> 
> So, how fast is cairo on other platforms? 

I have no real idea how complex your drawing is or how fast your
machine is, but the general order of magnitude of performance
sounds similar to what I'd expect.

> Is there a way to reduce the
> rendering time? (I need to draw a screen full of stuff, and the time
> approaches 100ms)

There is no magic "go faster" flag, no. Performance is definitely
still an active area of work and adding quality/performance knobs
doesn't make a lot of sense until we have some idea of how good
performance we can get with good quality.

On the Win32 side, one thing you can definitely try is to compare
rendering to a DIB with rendering to a DDB/Window ... if you
are rendering mostly bezier paths, using a DIB will be a big
performance win. On the other hand, if you are rendering mostly
text, rendering to a DDB may be significantly faster.

There's still quite a bit of work that could be done on the Win32
backend to improve performance when rendering to a DDB. There's
some notes about possible optimizations:

  http://lists.freedesktop.org/archives/cairo/2005-January/002755.html

But I don't know a way of making rendering antialiased bezier paths
to a DDB or Window truly fast using the GDI ... we need the operation
of expanding out a A8 mask with a constant color and composing in
one operation which isn't available. So, for rendering a complex
picture, rendering to a DIB is likely to be faster overall with GDI
even for a well optimized backend.

Eventually, making the Win32 backend optionally work on top of
Direct3D probably makes a lot of sense.

> Also, it seems that the time to draw a big picture is similar to
> drawing three 1/3 size ones. Ie the bottleneck isn't cairo's math, but
> rather rasterizeEdges() function which invokes
> AddAlpha(N_X_FRAC(N_BITS)) millions of times.....

Yes, trapezoid rasterization is the known problem. Carl is working
on a rewrite ... I don't know offhand when that is scheduled to
land or whether there is anything you can help with there.

Regards,
						Owen