After~20minutes of play, a dozen or so level transitions, and probably several hundred calls to image.getRGB(…) & Image.createRGBImage(…) - the handset will begin to throw an OutOfMemoryError from canvas.serviceRepaints().
This doesn’t appear to occur when getRGB/createRGBImage are not used.
Has anybody encountered this or similar issues on the N90 (or similar handsets) ?
Symbian phones sucks a lot, with a lot of bugs, some of them still since version 7.
I dont sure about N90, but many (or all?) symbian phones have problems when you use transform in drawRegion.
If the problem is that, u can use NokiaUI api to solve it. Nokia dont recomment it, but… it works.
Leak would be the wrong word. All images you load directly are set to native memory (yes, bob, bigger, better, slices, dices). When you try to free them, only the handle is freed, not the memory.
I think nokia defines it as a ‘feature’.
Many symbian phones have that feature though I cannot say how many due to lack of testing.
Best thing is to write a midlet that fills up memory with images, release a few and then try to load one again.
If it works for as many as you removed (might have gotten lucky and it freed up enough), great.
If not, it has the ‘feature’.
One version is to load everything once.
or
as you wrote, use either the midp 2.0 rgb feature (would work for all midp2.0 devices) or nokias direct graphics stuff (would work for all nokias + has some nice features).
But if you do it this way, do NOT load the images as pngs! Like I wrote above, the leak is the image!
Dump the contents to a file (compress just as well as a png) and load the file (which is loaded to java heap).
It turns out the cause of the memory leak was getDirectGraphics(…).
It was being called once per paint, but the returned DirectGraphics object was never being accessed.