GNOME Bugzilla – Bug 106960
Add option to disable all previews on images larger than some given size
Last modified: 2008-06-05 07:05:31 UTC
As mentioned by Toralf Lund in bug #106730 and as I have experienced personally while working on large images, updating the various previews (image and layers) can be a source of disk trashing (swap and/or tile cache) if the image is large. Even if this is done in an idle task, this can severely affect the performance of the system because of the frequent disk accesses and memory swapping. There is already an option that allows the user to select the size of the previews or to disable them completely. But this is not very flexible. It would be nicer to be able to keep the previews for smaller images. For instance, this would be useful if you have many small images from which you want to paste some parts into the large images. It would be nice to be able to select a maximum image size (in bytes) for the previews (similar to the existing option that generates a warning if a new image is larger than a given size). All images smaller than that size would get the automatically updated previews as usual. All images larger than that size would get no previews or would only get a "frozen" preview.
Wouldn't it be better to disallow the image preview code to invalidate tiles? So instead of having no preview at all, there would be a preview of the part of the image the tile-manager knows about w/o swapping in tiles, the part that is being worked on anyway. I just don't know how to present the fact that the preview is incomplete.
I really like the idea of partial previews (seems to be a nice and simple, and therefore good, way to deal with the problem), but size limit would also be OK. Also, with the current CVS version I get previews even if I set size to "None", but perhaps that's a separate issue?
I don't know if having a partial preview is really good from a user interface point of view, but it is an interesting idea. It would come close to what I meant with a "frozen" preview (if the whole image is available at least once). Here are some comments about this: * In some cases, I would like to be able to generate complete previews for some images even if they do not fit in memory, as long as they are not too big. For instance, I would like ot generate previews for the images that are only a few MBs bigger than the available memory, but not for those that are an order of magnitude bigger. So even if we allow partial previews based on what is available in the tile cache, it would be nice to be able to override that option. * The preview could now be complete or incomplete, but there is another state that is possible: complete with some outdated parts. I don't know if it should be represented differently from the incomplete state. * All states that are incomplete or partially out of date could be represented by a red border around the preview, although that would conflict with the way the layer masks can be viewed. * Instead of having a single flag saying if the preview is up-to-date or not, the preview code will have to keep a state mask for each pixel, requiring at least two bits per pixel to store one of the following states: 1 - The value of the pixel is correct and up-to-date. 2 - Partially correct: some tiles were not available when this pixel was computed, but the partial contents are up-to-date. So this pixel should only be recomputed if a neighboring tile is swapped in. 3 - Fully or partially correct, but out of date. The pixel should be was generated once and is now invalid. It should probably be kept until at least one of the corresponding tiles is available. 4 - Unknown. The value of this pixel has not been computed yet because the corresponding tiles have never been available. Alternatively, there could be two independent bitmasks: one saying if the value of the pixel was computed from all corresponding tiles or only from some of them, and the second one saying if the current value is up-to-date or not. Hmmm... It looks like this is not as simple as I thought at first...
The problem with the size limit is that we create image previews from layer previews. Images can contain layers of arbitrary size and layers can be contained in images of arbitrary size. Do we look at the image's size to disable layer previews or do we look at all layers' size to disable image previews? IMHO the size limit is unimplementable because GIMP does not have any image <-> layer size constraints. We should close this one as WONTFIX. Comments?
The limit should be on the total size (in bytes) of the whole image, so this would include all layers, layer masks, channels, etc. We are interested in the total amount of memory consumed by the image (or the maximum that could be consumed without COW tricks), because this is what matters when you want to avoid swapping and disk trashing. The total amount of memory does not need to be tracked at all times. It is important to set it when the image is first created or loaded and it would be acceptable from my point of view to use this initial value for deciding if the preview should be enabled or not. A smarter version would dynamically disable or enable previews when new layers are added, removed or resized (i.e., when the memory usage changes).
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
I agree with Mitch, we should close this as WONTFIX. If the previews are a performance problem, then we should fix that problem instead.
Closing as WONTFIX then.