<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE> <META content="text/html; charset=euc-kr" http-equiv=Content-Type> <STYLE id=mysingle_style type=text/css>P { MARGIN-TOP: 5px; FONT-FAMILY: 굴림체, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } TD { MARGIN-TOP: 5px; FONT-FAMILY: 굴림체, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } LI { MARGIN-TOP: 5px; FONT-FAMILY: 굴림체, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } BODY { LINE-HEIGHT: 1.4; MARGIN: 10px; FONT-FAMILY: 굴림체, arial; FONT-SIZE: 9pt } </STYLE> <META name=GENERATOR content=ActiveSquare></HEAD> <BODY> Thank you for reply. Please see (HKBAIK) indications.   Hyunki Baik ------- Original Message ------- Sender : Andrea Canciani<ranma42@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@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@cairographics.org > http://lists.cairographics.org/mailman/listinfo/cairo > &nbsp;&nbsp;Hyunki Baik Senior Engineer Samsung Electronics MOBILE. 82-10-7557-0107</BODY></HTML><img src='http://ext.samsung.net/mailcheck/SeenTimeChecker?do=49d54391e6acf7b9b55214a4e614e366ba120f24d84780d11aa3ee4d9bee60989d863d267dbfda2097b747f9fd0aa8f97978c4b304c8d0f1326bbdfb2ea96a2fcf878f9a26ce15a0' border=0 width=0 height=0 style='display:none'>