I got sent these (don't know precisely why). These are
mostly pretty reasonable or good ideas, many of which
have been discussed at one time or another if not committed
to an explicit TODO...
--
Adam D. Moss . ,,^^ adam@xxxxxxxx http://www.foxbox.org/ co:3
--- Begin Message ---
- To: adam@xxxxxxxx
- Subject: Suggestions
- From: Frank Klemm <pfk@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 15 Oct 2001 22:20:14 +0200
- >received: (from pfk@localhost) by fuchs.offl.uni-jena.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA32208 for adam@gimp.org; Mon, 15 Oct 2001 22:20:15 +0200
- Delivered-to: dial.pipex.com-ygv50@dial.pipex.com
I normally using Photoshop and normally larger images
(digital camera, dia scanners).
Some Ideas to improve performance:
Compressed Tile Cache
~~~~~~~~~~~~~~~~~~~~~
If a tile has a constant color, (size: 64x64, but all black), it would be
better to store the color of the whole tile (4 byte for RGBI) instead of
the whole tile (64x64x4 Byte = 16 KB).
Especially if using overlays, often only small ranges are actually used.
A tile can have 3 states: tile in RAM, tile on disk, constant color tile.
Startup with Zoom/Displacement
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I should be possible to select zoom and displacement on startup.
Expose Events
~~~~~~~~~~~~~
If a part of the image is hidden by an Gimp window, backbuffering is much
faster than repaint, especially if the image is displayed with small zooms
(1:4, 1:6, 1:8), so a lot of cache data from the tile cache must be reread.
Multithreaded
~~~~~~~~~~~~~
While an operation is running (filtering, but also expose event handling),
it should be possible to work with the program instead of a blocking
program.
Paletted Grayscale images
~~~~~~~~~~~~~~~~~~~~~~~~~
Often grayscale images are stored as index color images (with a stupid
palette with 0,0,0, 1,1,1 ... 255,255,255). In this case Gimp blows up
the image to 32 bit internally which slows down execution.
Tile Grouping
~~~~~~~~~~~~~
Tile size (in KByte) shoudl be estimated in a way that head seeking and
data reading need about the same time:
f_seek = 7.5 ms
f_latency = 5.5 ms -> 13 ms
datarate = 30 MB/s
30 MB/s * 13 ms = 400 KB
Tile size should be not much larger or much smaller than these 400 KByte.
A tile of 64 x 64 x 4 Byte has an size of 16 Kbyte, i.e. seeking times
will be much larger than disk reading times.
So tile cache should be store 16 tiles in one tile cache area, so
such a macro tile has an size of 256 Kbyte.
1 Macro tile = 16 tiles
1 2 5 6
3 4 7 8
9 10 13 14
11 12 15 16
Tile Cache on a raw device
~~~~~~~~~~~~~~~~~~~~~~~~~~
It should be possible to use a raw device (partition) as a tile cache
(if supported by the OS).
Tile Cache OS caching
~~~~~~~~~~~~~~~~~~~~~
If supported by the OS, a OS supported additional caching of swapped out
tiles should be disabled. This eats additional RAM, slows down
disk I/O, eats CPU time, trashed the disk cache for other processes.
--
Frank Klemm
PS. I have some (artifical) test images for system stress tests.
URL: ftp.iks-jena.de:/pub/mitarb/lutz/hacking/testbilder-klemm-?.png
On number 11 gimp fails.
--- End Message ---
