Improve rendering speed for displaying/scaling large image files

[GoogleCodeExporter]

Gargoyle is very fast at drawing graphics to the screen, when the source 
image files are relatively small (on the order of  2,500-350,000 total 
pixels). However, it lags behind Zoom and WinGit when the total number of 
pixels per image rises to the order of 950,000 (about 1280 x 760). Can 
rendering of large images be further optimized?

Original issue reported on code.google.com by Ek.Temple@gmail.com on 3 Mar 2010 at 9:48

[GoogleCodeExporter]

Here are some sample files. (All of them are versions of a GUI graphics editor 
I'm 
working on, so they may look a little unusual.) Most of the images are 
small-scale 
PNGs, the largest about 500 x 500 px. The images in the image library to the 
right 
are the ones that vary.

Small PNGs in image library ("control"--smaller images, generally about 2500 px 
each):
http://dl.dropbox.com/u/947038/Glimmr%20Canvas%20Editor.png

Large PNGs in image library (these are the screenshots of the editor itself; 
there 
are also a few smaller PNGs):
http://dl.dropbox.com/u/947038/Glimmr%20Editor_PNG.gblorb

Large JPEGs in image library (the same large images as in the previous, but 
JPEGs):
http://dl.dropbox.com/u/947038/Glimmr%20Editor_JPEG.gblorb

The easiest way to compare speeds is to note the initial time to open the 
editor 
windows, and then click on the first image in the image library at the right 
side. 
The image will be copied to the central window. Clicking elsewhere in the 
central 
window will then move the image around, giving a sense of the redraw rate. 

Original comment by Ek.Temple@gmail.com on 4 Mar 2010 at 2:00

[GoogleCodeExporter]

I can't seem to get either of those gblorbs to load.  I tested them with 
gblorb.ulx,
and it crashes while extracting the unknown resources:

PICT        337  JPEG     235088  PIC337
UNKN        338  UNKN  651251913  UNK338
UNKN        339  UNKN  867273337  UNK339
UNKN        340  UNKN  -21076728  UNK340
PICT        341  JPEG     211280  PIC341

Original comment by bcressey@gmail.com on 4 Mar 2010 at 9:17

• Changed state: Accepted

[GoogleCodeExporter]

Hm, neither of these give me any trouble at all--I can load them in Gargoyle 
(running through Wine on OS X) with no complaints, as well as in all other 
terps. I 
can also load them and extract all resources using gblorb.ulx. Maybe they were 
corrupted in the download? I've zipped them for added insurance:

http://dl.dropbox.com/u/947038/Glimmr%20Editor_JPEG.gblorb.zip
http://dl.dropbox.com/u/947038/Glimmr%20Editor_PNG.gblorb.zip

Original comment by Ek.Temple@gmail.com on 4 Mar 2010 at 9:46

[GoogleCodeExporter]

Looking at the imgload.c, it appears that images are not getting reliably 
cached in
memory on use.

So the issue may not necessarily be the speed of the scaling code, but the cost 
of
retrieving megapixel images from disk.

Original comment by bcressey@gmail.com on 4 Mar 2010 at 10:24

[GoogleCodeExporter]

The zipped files worked just fine, thanks!

Original comment by bcressey@gmail.com on 4 Mar 2010 at 10:25

[GoogleCodeExporter]

Seems like two optimizations are possible:

- Keep the initial image in memory, to avoid trips to disk
- Keep the most recent scaled version of the image in memory, to make moving the
image less costly.

The only advantage of the current approach is that the original image is always 
the
source for resize operations, but we can keep that behavior without the 
constant hit
to execution speed.

Original comment by bcressey@gmail.com on 4 Mar 2010 at 10:37

[GoogleCodeExporter]

Fixed in r328.

Original comment by bcressey@gmail.com on 22 Mar 2010 at 6:26

• Changed state: Fixed