Skin
API documentation
1. Used OOM policies, Who is handling OOM? and Description of flow
This module needs work on this area. It was designed for desktop (read: no OOM handling).
It uses OP_STATUS, but the init-function can also leave. The code mostly don't bother to report if OOM has occured.
There is also a lot of situations when ownership of memory is unclear, if created object is also added to a list and theirfore can't be deleted if another OOM occurs etc.
There might be code left that crashes if OOM occurs or leaks (Fixed a lot of it now when looking into the code.).
2. Heap memory usage
It depends on how much graphics the skin use. This varies a lot.
3. Stack memory usage
Low. No recursive functions.
4. Memory ownership
Memory ownership is kept inside the skinmodule. But internally it is a bit fuzzy.
5. Static memory usage
A pointer to g_skin_manager.
Some strings for skinpart-names.
6. Caching and freeing memory
The skinbitmaps is loaded first when they are needed but then kept in memory until the skin is unloaded (by changing it or exit opera).
7. Temp buffers
No tempbuffer is used. Temporary bitmaps is created on the fly when painting when specialeffects needs to be done.
8. Memory tuning
No tuning possible.
9. Tests
The current test checks for memoryleakage when creating a skinmanager and loading a skin.
10. Coverage
There is no automatically way to test coverage.