[FIXED] Serious painting and drawing apps NOT currently possible (Corona staff: please read)

Solar2D Advanced Graphics
#1

Our team has been utilizing several of the new features of graphics 2.0 and so far we’ve been loving it. There’s so much more you can do in Corona that wasn’t previously possible.

Especially useful to us is the new snapshot API, which opens up an extremely wide array of new possibilities— including painting/drawing functionality, which has even been mentioned on the Corona blog.

If you take a look at most painting/drawing apps on the app store, one feature they all have in common is **saving**. Make a drawing in 53 Paper and it’s still there when you come back to the app (exactly as it was when you left it — this is key, more on this in a moment). Same goes for just about every other app.

Currently the only way to save whatever you rendered to a snapshot in Corona is to use some of the screen capturing APIs in Corona, such as display.save, etc. The problem is, these APIs output a degraded JPEG. It’s not horribly degraded, but enough to notice… and any difference is unacceptable for a painting/drawing app, let alone a serious one. Further, the user’s work will be degraded *even more* every time they save. If you were creating a writing app, how happy do you think your users would be if every time they saved and loaded their file back up again, all the e’s were changed to Z’s and a plethora of other random changes were made to their file? Not very happy.

It is impractical to save every single stroke into a table and then “redraw” the user’s work every time they go to save/load. Not only would this disallow the use of “discard” canvas mode in snapshots (which would heavily degrade drawing performance and cause app crashes due to the sheer number of display objects that would need to be kept in memory), but the app would surely crash almost every time. Developers absolutely need to be able to render a snapshot to a file, and then load it back up later back into the snapshot.

A proposed solution: simply modify the display.save and other APIs that output JPEGs and give us a full-quality PNG option for iOS (PNG is already supported on Android).

#2

Saving to PNG is currently supported on all platform. Just change the extension of the output file name to “png”. The documentation has been updated to reflect this. Thanks.

#3

I submitted a bug on this already, but saving to PNG is heavily crippled. Any pixels that are partially transparent come out a very different color, as if they were composited over a black background. Though all fully transparent pixels remain transparent, so that’s a good thing. When it comes to painting apps, there’s definitely going to be pixels in “brush strokes” that are partially transparent.

I wasn’t given a casenum after using the bug submission form, so I can’t tell you which bug it is, but I attached a sample that clearly shows the issue if you can find it. I believe the title had display.save in it (but can’t be 100% sure, it was a few days ago).

#4

(Case 28844) display.save() to PNG distorts image if partially transparent

#5

As per Walter, this issue has been resolved as of daily build 2013.2111. Thanks!

http://developer.coronalabs.com/release/2013/2111/

#6

Unfortunately, not quite.  display.save() now appears to be applying a white background calculation to the pixels and therefore is not saving a .png which is 100% accurate.

#7

Saving to PNG is currently supported on all platform. Just change the extension of the output file name to “png”. The documentation has been updated to reflect this. Thanks.

#8

I submitted a bug on this already, but saving to PNG is heavily crippled. Any pixels that are partially transparent come out a very different color, as if they were composited over a black background. Though all fully transparent pixels remain transparent, so that’s a good thing. When it comes to painting apps, there’s definitely going to be pixels in “brush strokes” that are partially transparent.

I wasn’t given a casenum after using the bug submission form, so I can’t tell you which bug it is, but I attached a sample that clearly shows the issue if you can find it. I believe the title had display.save in it (but can’t be 100% sure, it was a few days ago).

#9

(Case 28844) display.save() to PNG distorts image if partially transparent

#10

As per Walter, this issue has been resolved as of daily build 2013.2111. Thanks!

http://developer.coronalabs.com/release/2013/2111/

#11

Unfortunately, not quite.  display.save() now appears to be applying a white background calculation to the pixels and therefore is not saving a .png which is 100% accurate.

#12

I’ve made a change today that will affect display.save() in tomorrow’s daily build. Could you let us know if it fixes your problem?

If not, please create a new fogbugz issue, with a sample, so I can debug your problem further. Thanks!

#13

Thank you Albert!  This bug has been causing us issues in various forms since November.  We really appreciate it and last night submitted two apps that were being held up by this.  +1 big time!

#14

I’ve made a change today that will affect display.save() in tomorrow’s daily build. Could you let us know if it fixes your problem?

If not, please create a new fogbugz issue, with a sample, so I can debug your problem further. Thanks!

#15

Thank you Albert!  This bug has been causing us issues in various forms since November.  We really appreciate it and last night submitted two apps that were being held up by this.  +1 big time!