Memory handling for gzz

Requirements

Because Gzz has rather peculiar memory usage (focus+context, glimpses of far-away things, ...), we need to take explicit control of the parts of the heap where large blocks are stored.

Initially, the most memory-intensive part are the large textures used e.g. in xupdf, so in the first stage, the system should be able to deal with these.

Especially the relationship between MemoryConsumer, MosaicTexture and MosaicTile is difficult: Textures consume a particular amount of memory, but MosaicTiles are the allocation/deallocation unit.

Loading large textures takes also time; view generation should be instantaneous. Because of this, when generating views, only requests for textures should be made, which are granted or not, based on the state of the texture.

In the above diagram, the first call creates the request, which is loaded in the background, and results in the image having been loaded when the request is made a second time. The client is notified when the image has been loaded.

Now, in order to not constrain the evolution of the rest of the system, we should have the different loadable types pluggable.

The class MemoryConsumer abstracts a single memoryconsumer, where the system may query it for the maximum number of bytes needed, the way the number of bytes can be scaled, and set the current memory consumption to a particular amount.

Defining the importance function is not simple; this represents the tradeoffs between memory use for the focus and context. The first, obvious quality is that the most immediate focus has priority: it must never be blurred to make the context sharper. In the other end of the scale are the spans that are not really visible but might become visible when the user moves; these should only be loaded if there's extra memory available.

The cases between the two extremes are the difficult ones.

Need to be able to handle case of 1 focus-request for A + 100 low-quality non-focus requests for B IN A SINGLE VOBSCENE.

As an example of how this system will be tied to the rest of Gzz, consider PageSpans and OpenGL. The basic operation is: "get a texture rectangle for the given pagespan". In order to have the information about the relative importances of the textures come through, we need to give another parameter, the importance, when getting the texture rectangle.

The loading of a texture from an image file is an intricate process: first, the image is loaded into a memory buffer in a background thread. Then, the image must be loaded from the buffer to the OpenGL graphics memory - but herein lies a snag: this loading must be done in the OpenGL context, which is usable only in the main thread, and also this loading may take considerable time if texture compression is used. Thus, the loading will be done piecemeal, subimage by subimage, and always in between new events are checked for.