Road to pixman 0.16.0

[Olaf Schmidt]

"Rainman Lee" <rainman.lee at gmail.com> schrieb im Newsbeitrag
news:54897a550907140309k12cd7277pf8996e087c8c9c25 at mail.gmail.com...
> >
> > Let me know if I missed anything.
> >
>
> I thought the performance for rotating should be improved,
> especially on windows.
I'd doubt, that the rotation-performance of pixman is the
culprit for the bad performance (compared with GDI+).
IMO this is caused by the final rendering (blitting) of your large
buffer (defined 1400x900) back to a Window-hDC.

I've just tested your code you've posted earlier here on my
machine with different cairo-surfaces (DDBs and DIBs -
and also with a free defined 32Bit ImageSurface-Buffer) -
and I get approx. the results below (including the final
rendering to the hDC ...the Destination-Window maximized
on a 1680x1050 screen):

DDB   = 3.60sec
DIB = 3.03sec
32Bit-Plain = 2.99sec

And these are the results, if I comment out the final rendering
of your larger Buf-Surface to the Window-hDC (pure rotation):
DDB   = 1.85sec
DIB = 1.05sec
32Bit-Plain = 1.06sec

The DDB the slowest of the three approaches (mainly caused by
the fact, that PixMan cannot perform its operations directly
on a DDB-surface, since it doesn't offer a direct MemAccess
as the other two - but with somewhat more speed at the final
Blt to the Window-hDC - so there's always a tradeoff with DDBs,
depending on the Surface-Sizes (faster final rendering to
Window-DCs, but slower performance whilst working
"within" cairo or pixman).

If we look at the differences (which you can deduce the
pure, final Blt-Times from):
about 2sec BltTime for the both "pure Memory-Buffers".
and about 1.7sec for the final Blitting of the DDB-based
Surface.

> I run a test which painted a rotated image pattern from 0 degree to
> 360 degree, with fast filter, and no antialias.
> cairo takes 3448ms, but GDI+ takes only 1411ms, more than two
> times faster than cairo!
I'm sure, GDI+ has a fastpath available, to transfer its memory-
buffers (e.g. after the performed rotations) into the graphics-card-
memory for the final Blit to the Window-hDCs (over DirectX).

You can achieve that "by hand" too, if you use the fast "texture-
transfer-modes" of a DirectX-Binding of your choice - to put
e.g. a plain 32Bit-Cairo-ImageSurface (with correctly matching
stride) into the graphics-memory per AGP or PCIe, and do your
final blitting from there (to your Window-hDC) - or alternatively
use the Win-OpenGL-API for that.

I'm about to finish my COM-based Cairo-wrapper now - and
there I've included a DirectX-Binding already (nothing special,
only for these final transfers of the Cairo-Memory-Surfaces
into the gr.-memory and then the DX-Blitting to the Windows
in question from there).

With that "extension" I achieve about 1.35sec here on my machine
(running the same test), and that is IMO in the GDI+ range now
(if not faster).

The test performed on a maximized Window (1680x1050 screen).
The BackBuffersize, which the rotation was performed against was
1400x900 as in your example - the png-image 300x300Pixels,
including a transparency-channel.
Testmachine a 3year old Notebook (2x1.8GHz) with one
of the cheaper ATI-mobile-cards.

Maybe you can give some infos about your png-image-size -
and if you ran your test against a maximized-Window in both
cases (GDI+ and Cairo).
Especially the png-size would be of interest (to make our timings
more comparable with my results).

As said, from my point of view cairo/pixman is fast enough here
(on a cairo 1.8.2-compile) - you only need to find a way, to
render from your larger BackBuffer directly into the gr.-card,
if you have an interest in such high framerates of about 250FPS,
which my directx-blitted "rotation-test" has shown (and your
GDI+ test apparently too).


Olaf