[cairo] Regarding performance and memory usage of the recording surface

[Andrea Canciani]

On Fri, May 27, 2011 at 4:34 AM, 백현기 <hyunki.baik at samsung.com> wrote:
> Hello all,
>
> I have been testing the web-browser application which uses cairo recording surfaces.
> I have found that cairo uses a large amount of memory (more than 250MB) when I try to perform panning operations to navigate a web-page with a high zoom rate (e.g. NYTimes. The page size with 4x zoom rate is 3888x14324). Sometimes system crash occurred on that situation.
> I have investigated the reason and it turns out that there are many snapshot images created by replaying process for recording surfaces. (In fact, more than 10,000 recording surfaces(128x128 ARGB pixels) can be used for above situations.)
>
> And I think the replay process can be improved if it can replay recorded operations onto destination surface directly (not snapshot image) when the operation is SRC operation and size between recording surface and destination surface is equal. (i.e. transformation matrix has only a translation vector.)
> I have tested the performance for replaying operation between original cairo recording surface replaying and modifed replaying version which do not have snapshot images and perform the replaying onto destination surface directly.
> (I have modified the _composite_boxes() funtion in cairo-image-surface.c file and the _cairo_recording_surface_acquire_source_image() in cairo-recording-surface.c file.)
> In the experiment, up to 2x speedup can be observed.
>
> Based on that situation, I'd like to ask some questions.
>
> (1) Do you have a plan to support "disable snapshot mode" for the recording surface? (by parameter when recording surface is created or by build option)

I'm not sure I understand what this mode is supposed to do. Could you
explain it?

> (2) Do you have a plan to support "direct replay mode" to destination surface to avoid the additional copy from snapshot to destination surface if the snapshot is not used and the operation between recording and dst surfaces is 1:1 src operation. (i.e. bit-blit operation)

There is some support for "direct replay mode" in some backends, but
it is currently a backend-dependent feature.
It would be nice to have the ability to detect if the recording
surface can be just replayed on the
destination surface and it should not be too hard at least in trivial
cases (currently paint and fill operations, when
we add support for stroke-to-path, stroke ops, too).
For example it would also be possible to do this kind of optimization
for other operators, in particular OVER
(it simply depends on the associativity of the operator).

>
> I also like to ask to review my source code patch to support above (1) and (2).

You forgot to attach/link the patch.

Andrea

>
> Thank you very much.
>
>
> Hyunki Baik
>
> Senior Engineer
> Samsung Electronics
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>