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

Fri Jun 3 01:02:10 PDT 2011

2011/6/3 조영환 <yhwan.cho at samsung.com>

>  Hello.
>
>
>
> It's delivering patch.
>
>
>
> I'm younghwan working with HKBAIK on this issue.
>
>
>
> please see and review the patch file attached.
>

I believe that the change in cairo-image-surface.c is incorrect.
How is it supposed to handle the various repeat modes?

The change in cairo-surface-snapshot.c  seems correct. I wonder
if it would be better to limit the (total) size of snapshots or doing
some similar trick to avoid replaying the snapshot multiple times
when using it more than once as a source.

It should also be noted that the current way of creating the
snapshot is incorrect, as pointed out in this bugreport:
https://bugs.freedesktop.org/show_bug.cgi?id=30282

Fixing this bug will make reusing the old snapshot less likely,
so something like the no-snapshot approach you suggest might
become the default.

Andrea

>
> Younghwan.
>
>
>
> ------- *Original Message* -------
>
> *Sender* : 백현기<hyunki.baik at samsung.com> E5(책임)/책임/System S/W그룹(무선)/삼성전자
>
> *Date* : 2011-05-27 16:31 (GMT+09:00)
>
> *Title* : Re: [cairo] Regarding performance and memory usage of the
> recording surface
>
>
>
> Thank you for reply.
>
> Please see (HKBAIK) indications.
>
>
>
> Hyunki Baik
>
> ------- Original Message -------
> Sender : Andrea Canciani<ranma42 at gmail.com>
> Date   : 2011-05-27 14:41 (GMT+09:00)
> Title  : Re: [cairo] Regarding performance and memory usage of the
> recording surface
>
> 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?
>
>
>
> (HKBAIK)
>
> As I described below, when I navigate the highly zoomed web page, cairo
> recording surface takes a larget amount of memory because of snapshot images
> for their 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.
> When I commented out the line "_cairo_surface_attach_snapshot
> (&surface->base, image, NULL);" in
> _cairo_recording_surface_acquire_source_image() function in
> cairo-recording-surface.c file, it doesn't take a large memory any more even
> if it doesn't give caching effect for second replay. (i.e. as like the first
> replay, second replay also requires operation-level replay again, not using
> the snapshot image.)
>
> Therefore, to avoid to allocate unlimited memory size for snapshot images
> from recording surfaces, I think it would be comvenient if some options
> about snapshot management are provided as below.
>
> (1) manages all snapshot images for all recording surfaces
>
> (2) do not keep a snapshot image after replaying the recording surface (I
> know, it requires operation replaying process for subsequent replays. but
> this option can be useful if the application or library which uses cairo
> library also have the bitmap cache for already replayed surfaces.)
>
> (3) manages snapshot images pool up to specified maxmimum size as like the
> cache pool (ex: 50MB, 100MB...)
>
>
>
> > (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).
>
> (HKBAIK) In addition to above scenario, it would be also helpful if the
> recording surface do not use the snapshot image. (I mean "disable snapshot
> mode" as metioned above.)
>
>
>
> >
> > I also like to ask to review my source code patch to support above (1)
> and (2).
>
> You forgot to attach/link the patch.
>
> (HKBAIK) I am cleaning codes now, i'll share it soon. sorry for the
> confusion.
>
>
> 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
> >
> <p>&nbsp;</p><p>&nbsp;</p>Hyunki Baik
>
> Senior Engineer
> Samsung Electronics
>
> MOBILE. 82-10-7557-0107
>
>
>
>
> Hyunki Baik
>
> Senior Engineer
> Samsung Electronics
>
> MOBILE. 82-10-7557-0107
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110603/d4f5340d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 72722 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110603/d4f5340d/attachment-0001.jpeg>