Optimize memory used for multiple clipped images with a common backing image

[GoogleCodeExporter]

If SVG Web is used as a raster engine, requiring a lot of image sprites, it
may make sense to organize the graphics into one or more large images to
optimize network transfers. Instance of small sprites can be used by
referencing the same large image with a different clip to produce many
different sprites.

However, creating many instances of the same image with different clips
currently consumes the full amount of memory for the entire image for every
instance created, no matter how much of it is clipped. The potential
optimization is to recognize simple rectangular clips and only create
bitmaps that are the size of the clipping area. This relies on the
implementation of Issue 344 so that all sprites clipping the same image
shared a common unclipped image instance.

Original issue reported on code.google.com by grick23@gmail.com on 11 Oct 2009 at 8:16

[GoogleCodeExporter]

Thanks for showing interest to improve this. I'd like to add that both memory 
usage
and rendering speed would have to be improved. Here is a testcase:
http://www.pvv.ntnu.no/~andrearo/blocks_game.html

Original comment by andre...@pvv.ntnu.no on 13 Oct 2009 at 7:33

[GoogleCodeExporter]

Any news on this issue? I would really like this improvement for this project:
http://code.google.com/p/freeciv-forever/

Original comment by andre...@pvv.ntnu.no on 17 Nov 2009 at 10:18

[GoogleCodeExporter]

Unfortunately, not any good news to report yet. I have code that implements 
this 
optimization, but it did not save the memory I was expecting but I was not sure 
why. 
I had to set it aside to work on other things. I'll see if I can take another 
look 
at this over the weekend.

Original comment by grick23@gmail.com on 19 Nov 2009 at 8:16

[GoogleCodeExporter]

I think I have made a breakthrough on this Issue. The memory seems to be 
consumed 
because the SVGImageNode Sprite is still specified as having the full image 
height 
and width even though the child bitmap createe for it is optimized to be much 
smaller. This should not have been an problem, except that we use cacheAsBitmap 
by 
default on nearly all nodes and so the SVGImageNode sprite will consume memory 
for 
the full image area even though it only has a little bitmap as a child.

I still need to validate a solution, clean up some loose ends, and test before 
it 
will get checked in. It may still be a few days, but I should have something 
checked 
in by the end of this coming weekend.

Original comment by grick23@gmail.com on 26 Nov 2009 at 12:44

• Changed state: Started

[GoogleCodeExporter]

Great, I'm looking forward to testing this out. It would be interesting to see 
how
well the improved svgweb does on the test-case in comment #1.

Original comment by andre...@pvv.ntnu.no on 26 Nov 2009 at 9:54

[GoogleCodeExporter]

Fixed in r1008:

Issue 345; Optimize memory usage for the situation where there are multiple 
clipped
images from a common composite backing image. The common bitmap data is kept in 
a
dictionary and smaller bitmaps are created from this bitmap.

Also, a separate optimization is implemented related to the cacheAsBitmap 
property of
flash objects so that we do not use this for bitmaps.

--

From searching around a bit, I think I have implemented the best practices for
optimizing bitmap memory usage, and combined with Issue 344, memory usage is 
down
80+% for the test case in comment #1.

Unfortunately, flash still consumes a lot of memory and I am out of ideas for 
now on
improving this area of code. It would take another 'flash' of inspiration in 
order to
improve this further.

Original comment by grick23@gmail.com on 27 Nov 2009 at 9:57

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for looking at this issue. I'll give it a try.

Original comment by andre...@pvv.ntnu.no on 27 Nov 2009 at 10:09

[GoogleCodeExporter]

I think Issue 432 is a regression caused by this.

Original comment by bradneub...@gmail.com on 30 Nov 2009 at 10:39