Hello raster and other evas gurus, last week we were confronted with memory usage peaks when rotating a canvas through elm_win_rotation_with_resize_set.
We didn't really understand what was going on and so we came up with a patch which seemed to fix the problem: http://git.enlightenment.org/core/efl.git/commit/?id=139737247d563f53a064c7f4a025a89ed64c2983 We now know that this fix was just stupid and doesn't really work (or fix anything). After some more digging into the render code we have learned so far (please correct any place where we're wrong): * Only changed regions get rendered * For each region a new region_for_update is allocated with evas_software_xlib_outbuf_new_region_for_update() * The image returned by this function is updated with the image data for the region * evas_software_xlib_outbuf_push_updated_region() takes care of any conversion (colorspace, rotation) that might be necessary * evas_software_xlib_outbuf_flush() sends the updated regions to X * After the rendering is done the stuff allocated through *outbuf_new_region_for_update is freed again In the common case (rotation is 0, display depth is 32bit): * outbuf_new_region_for_update() allocates an XShmImage and attaches its data directly to the evas_image data. * outbuf_push_updated_region() detects this case ( -> if (data == (unsigned char *)src_data) ) and skips any convert function In any other case (i.e. rotation is 90, 180 or 270): * outbuf_new_region_for_update() allocates data for the evas_image. This is where the updates will get rendered into. It also allocates an XShmImage which is what will be pushed to X in outbuf_flush(). The dimensions of the XShmImage is transposed if the rotation is 90 or 270. * outbuf_push_updated_region() selects the appropriate conversion function and updates the XShmImage with the rotated image. What now happens if we rotate a large window is that the complete canvas needs to be redrawn - resulting in a large allocation of both the original image and the rotated XShmImage. After that initial large update we only have to update smaller regions so this is a one-time spike. The question is now how do we reduce the allocation peaks when rotating large windows? One possibility we see is breaking up the one large fullscreen update into smaller ones and rendering those sequentially. Does that make sense? Is there another/better way? Regards, Stefan and Daniel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
