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.