PNG quantisation and memory usage
Monkey Archive Forums/Monkey Discussion/PNG quantisation and memory usage
| ||
| 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? |
| ||
| 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 |
| ||
| Thanks, was thinking about Android as target. I'm fighting against an out of memory error. |
| ||
| 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. |
| ||
| What's the DDS error log from the OOM error? |
| ||
| 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) |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
   |