Hello,
We are currently developing a painting app and have a paintbrush that uses graphics (pngs) as a brush. The issue that we are having is that with excessive use of the brush tool, performance of the app decreases proportionately to brush use.
Does anyone have recommendations for how to deal with this issue?
All the best,
Jacob
Try creating images not as loaded from single file but create image sheet and draw images from it. It will improve some performance for sure.
a “painting app” is perhaps one of the worst use-cases for Corona, given that it’s OpenGL-based (as opposed to pixel-buffer based) – everything on-screen has to be re-rendered every frame. above some threshold, no amount of “sprite-optimization” tricks are going to help. if your app ever has “down time” you might be able to do a snapshot and swap out all current dynamic paint for a static image, then start accumulating again, repeat. not many other options come to mind.
your paint ‘line’ could be an array of coordinates and every frame you could redraw this with vectors, but I would personally try davebollingers method which should work - detailed more below.
display.capture is your new friend.
I would make it so every time you put down and lift your brush (finger) all paint data (images for that session) have been placed inside a separate display group for that session.
Straight after every new paint session - If any historic session is more than 10 lines old (or whatever threshold you want to preserve history), then put it into a special display group you use for capturing. This special group would contain any old captures (if one exists) and the new groups (sessions) you put on top. Capture this group and remove everything no longer needed (i.e all the stuff that makes up this one new image capture). This should greatly reduce the memory use of these paint lines, after all it will only ever be one full screen image and the most recent paint line images that are loaded.
Hope that makes sense, this method worked perfect for me for a flash application. The only limitation is that the ‘capture’ is constrained to what is displayable on the device screen at the time. You could do some fancy moving things about and capturing things in pieces if you wanted to scroll up/down left/right - but that is a bit more in depth for now.
Try creating images not as loaded from single file but create image sheet and draw images from it. It will improve some performance for sure.
a “painting app” is perhaps one of the worst use-cases for Corona, given that it’s OpenGL-based (as opposed to pixel-buffer based) – everything on-screen has to be re-rendered every frame. above some threshold, no amount of “sprite-optimization” tricks are going to help. if your app ever has “down time” you might be able to do a snapshot and swap out all current dynamic paint for a static image, then start accumulating again, repeat. not many other options come to mind.
your paint ‘line’ could be an array of coordinates and every frame you could redraw this with vectors, but I would personally try davebollingers method which should work - detailed more below.
display.capture is your new friend.
I would make it so every time you put down and lift your brush (finger) all paint data (images for that session) have been placed inside a separate display group for that session.
Straight after every new paint session - If any historic session is more than 10 lines old (or whatever threshold you want to preserve history), then put it into a special display group you use for capturing. This special group would contain any old captures (if one exists) and the new groups (sessions) you put on top. Capture this group and remove everything no longer needed (i.e all the stuff that makes up this one new image capture). This should greatly reduce the memory use of these paint lines, after all it will only ever be one full screen image and the most recent paint line images that are loaded.
Hope that makes sense, this method worked perfect for me for a flash application. The only limitation is that the ‘capture’ is constrained to what is displayable on the device screen at the time. You could do some fancy moving things about and capturing things in pieces if you wanted to scroll up/down left/right - but that is a bit more in depth for now.