The thumbnails module is a framework for generating and caching thumbnails.
Thumbnails wiki page
Most of the public API of the thumbnails module is exported through the
ThumbnailManager class which is accessible
from the global object g_thumbnail_manager.
There are currently three different modes of thumbnail generation. This is specified by using the OpThumbnail::ThumbnailMode values.
Use ThumbnailManager::GetThumbnailForWindow() to generate a thumbnail from an already opened window.
When generating thumbnails for e.g. speed dial you don't always have a window and a document ready screen shot. In those cases you can instruct the thumbnails module to generate a thumbnail from any given URL. This is a significantly heavier and more complex operation than just screenshotting an open window.
First of all you need to setup a listener to retrieve the thumbnail when it has been generated. Implement the ThumbnailManagerListener interface and add it with ThumbnailManager::AddListener().
Use ThumbnailManager::RequestThumbnail() to request a thumbnail to be generated. The URL will be loaded in the background, when the loading is finished a thumbnail will be generated and announced through the ThumbnailManagerListener.
To avoid having to regenerate all thumbnail everytime they are needed there is a built in cache.
RequestThumbnail() will automatically return thumbnail from the cache if possible. To keep track of
which thumbnail to keep in cache the URL's are reference counted. Use
ThumbnailManager::AddThumbnailRef() and
ThumbnailManager::DelThumbnailRef() to increase and
decrease the counter.
Descriptions of tweaks that can be used to tweak performance and memory usage. For a full list see module.tweaks.
By default the thumbnail manager handles all requests in parallell. If this tweak is enabled the request will be handled on by one.
Syncing nine speed dials to a clean profile would for example cause nine documents to load in parallell in the background with the performance and memory consumptions that imply. If this sounds like a bad idea on your platforms you want to enable this.
Generated thumbnail are stored in a disk cache. To limit the amount of disk used you can set this tweak.
There are currently three different thumbnail modes and they have different impact on memory usage. See OpThumbnail::ThumbnailMode.
Viewport is the standard mode. A screenshot of the whole viewport is taken
and scaled down. This mode also has the highest impact on heap memory usage since a big
bitmap, size of the viewport, is needed for the intermediate storage of the screen.
ViewportLowQuality is a low quality version of ViewPort. It paints
a scaled version of the viewport directly to the thumbnail which eliminates the need for
intermediate storage. This greatly reduces peak heap usage but may on the other hand result
in poor thumbnail image quality. This is largely dependent on the painters ability to paint
scaled views.
The third mode is FindLogo where the thumbnail manager tries to generate a
(non-scaled) thumbnail of a logo image in the document.
External API's returns OpStatus::ERR_NO_MEMORY or NULL pointers on OOM.
The thumbnails module will typically fail to generate a thumbnail on OOM and report this to the caller. The caller is responsible for having an appropriate fallback behavior. The module will deal with any necessary internal clean up.
The thumbnails module has a potentially big heap usage; both directly by using big buffers to render the thumbnail and indirectly by loading pages in the background. See the tweaks section on how to limit the heap usage.
There are no recursive calls in thumbnail and stack usage is small in general.
Small.
Use ThumbnailManager::Purge() to clean up the memory cache.
All allocated memory is deallocated by the ThumbnailManager when the module is destroyed.
No temp buffers are used.
See the Tweaking performance and memory usage sections.
There are currently no test regarding memory usage