PNG quantisation and memory usage

Monkey Archive Forums/Monkey Discussion/PNG quantisation and memory usage

Volker(Posted 2014) [#1]
Do .png files, which are compressed with tools like tinypng.com
do use the same amount of RAM as uncompressed ones, or can I save
not only diskspace but although memory usage?


ElectricBoogaloo(Posted 2014) [#2]
Depends on the target, and how the system handles it's data, but for the most part it wouldn't matter how it's compressed. In general when a system loads an image, it keeps it in memory as raw as it possibly can, so once loaded it'll usually just end up as a bunch of 32-bit ARGB values, no matter how it was originally compressed.
Compression saves on disk space, and download size, though, so is generally good practice. Just don't go crazy with the pics :D


Volker(Posted 2014) [#3]
Thanks, was thinking about Android as target. I'm fighting against an out of memory error.


AdamRedwoods(Posted 2014) [#4]
Thanks, was thinking about Android as target. I'm fighting against an out of memory error.

you can use RGB565, which will save some memory but there is no alpha channel.
otherwise, depending on the android version, you can try to use largeHeap in the manifest file, although it should be a last resort.


muddy_shoes(Posted 2014) [#5]
What's the DDS error log from the OOM error?


Volker(Posted 2014) [#6]
I want to update a pretty old app, which is created with Monkey V44.
But with Monkey V74a it crashes.
I've increased the heap size, without success. Crashes later, but crashes.


02-05 00:10:01.843: E/AndroidRuntime(13749): FATAL EXCEPTION: GLThread 11
02-05 00:10:01.843: E/AndroidRuntime(13749): java.lang.OutOfMemoryError
02-05 00:10:01.843: E/AndroidRuntime(13749): at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:43)
02-05 00:10:01.843: E/AndroidRuntime(13749): at java.nio.ReadWriteHeapByteBuffer.<init>(ReadWriteHeapByteBuffer.java:47)
02-05 00:10:01.843: E/AndroidRuntime(13749): at java.nio.BufferFactory.newByteBuffer(BufferFactory.java:49)
02-05 00:10:01.843: E/AndroidRuntime(13749): at java.nio.ByteBuffer.allocate(ByteBuffer.java:49)
02-05 00:10:01.843: E/AndroidRuntime(13749): at com.tireless.sslander.gxtkSurface.Bind(MonkeyGame.java:2235)
02-05 00:10:01.843: E/AndroidRuntime(13749): at com.tireless.sslander.gxtkGraphics.Flush(MonkeyGame.java:1616)
02-05 00:10:01.843: E/AndroidRuntime(13749): at com.tireless.sslander.gxtkGraphics.EndRender(MonkeyGame.java:1758)
02-05 00:10:01.843: E/AndroidRuntime(13749): at com.tireless.sslander.c_GameDelegate.RenderGame(MonkeyGame.java:7791)
02-05 00:10:01.843: E/AndroidRuntime(13749): at com.tireless.sslander.BBGame.RenderGame(MonkeyGame.java:584)
02-05 00:10:01.843: E/AndroidRuntime(13749): at com.tireless.sslander.BBAndroidGame.onDrawFrame(MonkeyGame.java:1320)
02-05 00:10:01.843: E/AndroidRuntime(13749): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1388)
02-05 00:10:01.843: E/AndroidRuntime(13749): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1138)




muddy_shoes(Posted 2014) [#7]
Read this from post 12: http://www.monkeycoder.co.nz/Community/posts.php?topic=2589&page=1

Be sure to read from post 22 through to the end as the solution evolves.


AdamRedwoods(Posted 2014) [#8]
Be sure to read from post 22 through to the end as the solution evolves.

Mojo is allocating an int array, and THEN allocating a byte buffer. eeek!
the IntBuffer wrap seems to be the way to go.


muddy_shoes(Posted 2014) [#9]
I'd have thought the GLUtils call would be best. It was certainly much faster when I tested back then. Compatibility is always the problem with Android and I don't have the experience to state anything is the one true answer. Then again NSS has probably the biggest reach of any Monkey app and Simon never came back to say it had broken other than not working for JPGs. Presumably it's still running with the mojo change from that thread.