2 ms·
I wrote a painting app with layer support a while ago for Android that had to use similar tricks (the app is coincidentally called Fresco: https://play.google.c
by seanwilson 12y ago
I wrote a painting app with layer support a while ago for Android that had to use similar tricks (the app is coincidentally called Fresco: https://play.google.com/store/apps/details?id=org.seanw.fresco.lite https://play.google.com/store/apps/details?id=org.seanw.fres...).
Each image layer (like you would have in GIMP or Photoshop) takes a couple of MB to store in Java and given the roughly 16MB Java app memory limit you didn't have much memory left to play with after creating 5 layers. I found that apps that used C and the NDK had no such limit; you could allocate huge amounts of memory compared to Java without any issues.
To take advantage of this, I wrote code that would let me allocate C memory, copy a Java bitmap into it then free the Java memory. To make all the app features work without crashes due to Java hitting the memory limit, I would shuffle bitmap memory between Java and C as needed, while having to implement several algorithms in C that I would rather have done in Java. For example, the undo/redo feature needed to store bitmaps of what changed when edits were made so this was mostly kept in C. One tricky issue was I couldn't find a way to get the Java APIs to render image data that was stored in memory used by C; you had to copy the data back into Java first.
I found the above frustrating in that if you're writing an image manipulation app, it means there is a massive incentive to avoid the native Java UI libraries and write your app entirely in C as you don't have the same memory limitations for some reason.
- realrocker 12y ago"you could allocate huge amounts of memory compared to Java without any issues". No sir. It still comes under the process memory account. It works in practice because coincidentally other processes were not using that memory.
- seanwilson 12y agoWell, I meant that if you hit the Java memory limit your app was guaranteed to crash but C allowed you to use an order of magnitude more memory without noticeable consequences when your app was in the foreground. Your app was probably more likely to be closed when it went in the background but that wasn't an issue.
- deleted 12y ago[deleted]
- pavlov 12y ago...I couldn't find a way to get the Java APIs to render image data that was stored in memory used by C; you had to copy the data back into Java first. I think you could use a GPU surface for that. On iOS there's IOSurface, which is basically a GPU-accessible memory buffer from the window manager that can be shared between processes. AFAIK there's something similar on Android, but I'm not sure off-hand what it's called. The idea is to get a surface and blit your image there on the C side; then access that surface as a texture on the Java side and draw it directly into a view. That way the pixels are never touched by the Java code.
- seanwilson 12y agoThis was around the Android 2.1 days; I considered switching to OpenGL but I think I was deterred by inconsistent device support at the time and thought the Java option was less of a headache. I'd be very interested in more details about the solution you mentioned!
- on_and_off 12y agoAFAIK all the serious Painting apps on both Android and iOS are implemented in OpenGL. The native UI frameworks of these platforms are not designed for this very specific usecase.