Builds 2016.2928 and 2016.2931 - display.save

Solar2D Daily Builds and Public Releases
#1

The notes for builds 2016.2928 and 2016.2931 state the following about display.save. I have not tried with these new builds (yet) but prior to these builds I had been experiencing intermittent issues with display.save saving blank images instead of the display object to the file system. The issue only occurs on the device and is not easy to reproduce (both iOS and Android). But it has happened often enough that I cannot rely on display.save so I have removed it from my code. Can I please get more details about what was actually fixed in regards to display.save in these recent builds? I could certainly do my own testing to see if my issue has gone away, but if the past is any indication, the issue could appear to have been resolved and then after several days just “randomly” happen again. Needless to say, I’d like more clarity on these fixes before spending more time on this. Thank you!

  • Core: fixing new display objects not triggering scene update after display.save()
  • Core: fixing culling offscreen objects with display.save. Casenum 43011
#2

I should add that the objects I have attempted to save are ImageRects whose texture was dynamically generated into a CanvasTexture. Furthermore, these ImageRects are off-screen when display.save is called. Specifically, they are placed at x, y = -1000, -1000. Their alpha=1 and isVisible =true. And I wait exactly 24 frames (in an app that runs at 30 fps) between the time the object is created until the time the object is saved.

#3

Yes, the bug with images being saved partially blank was fixed. It is possible that you’re encountering some other issue, we don’t know about.

Saving images containing TextureResourceCanvas can be tricky because canvases are not rendered immediately, they are rendered before next frame starts. So to save it you may have to wait for it to be rendered to memory.

I think easies way would to know for sure would be to try. I don’t know your particular case, but our test cases pass OK.

#4

Thank you Vlads. Your first sentence is what I wanted to hear. Since making my post this morning I did think of a way to create a reproduce-able test case. When I get a chance I will write it up and give display.save() a try again.

Regarding the delay for the canvas texture, I have already addressed that. I have a custom frames library that behaves just like the timer library except that unlike timer.performWIthDelay(), my frames.performWIthDelay() function delays by a specified number of frames. As alluded to above, I use this library to delay 24 frames between the time I render to the canvas to the time I call display.save().

#5

There is still a bug with display.save() and display.capture() if the object is partially out of the display area you will get a black image. This has been a bug since 2012…

#6

here is the original issue documented

https://forums.coronalabs.com/topic/19668-black-displaycapture-images-bug-773/

#7

I believe this is solved in recent daily builds, isn’t it?

#8

I am using the newest release 2949 and still have the issue, unless there is a daily build that fixes it? The issue is old so I figures it would be in a release build.

#9

Can you please provide sources to reproduce it?

Also, please, try on recent daily build, 2016.2972.

#10

I have done some more research and used build 2016.2972  this is what happens:

I am creating a 25x25 tile map using a 132x127 pixel 2kb image when I take a display.capture with captureOffscreenArea=true I get a black image.

If I take the same 25x25 and do a display.capture with captureOffscreenArea=false it works

Both methods work in the simulator but the display.capture does not work on my LG G3 using captureOffscreenArea=true.

#11

Ah! So the problem is on device… This may require some looking into. Because all my tests in Simulator worked OK. Please, be more specific what is your OS/Device.

Thank you!

#12

I am using a LG G3 android version 6.0.1

#13

I should add that the objects I have attempted to save are ImageRects whose texture was dynamically generated into a CanvasTexture. Furthermore, these ImageRects are off-screen when display.save is called. Specifically, they are placed at x, y = -1000, -1000. Their alpha=1 and isVisible =true. And I wait exactly 24 frames (in an app that runs at 30 fps) between the time the object is created until the time the object is saved.

#14

Yes, the bug with images being saved partially blank was fixed. It is possible that you’re encountering some other issue, we don’t know about.

Saving images containing TextureResourceCanvas can be tricky because canvases are not rendered immediately, they are rendered before next frame starts. So to save it you may have to wait for it to be rendered to memory.

I think easies way would to know for sure would be to try. I don’t know your particular case, but our test cases pass OK.

#15

Thank you Vlads. Your first sentence is what I wanted to hear. Since making my post this morning I did think of a way to create a reproduce-able test case. When I get a chance I will write it up and give display.save() a try again.

Regarding the delay for the canvas texture, I have already addressed that. I have a custom frames library that behaves just like the timer library except that unlike timer.performWIthDelay(), my frames.performWIthDelay() function delays by a specified number of frames. As alluded to above, I use this library to delay 24 frames between the time I render to the canvas to the time I call display.save().

#16

There is still a bug with display.save() and display.capture() if the object is partially out of the display area you will get a black image. This has been a bug since 2012…

#17

here is the original issue documented

https://forums.coronalabs.com/topic/19668-black-displaycapture-images-bug-773/

#18

I believe this is solved in recent daily builds, isn’t it?

#19

I am using the newest release 2949 and still have the issue, unless there is a daily build that fixes it? The issue is old so I figures it would be in a release build.

#20

Can you please provide sources to reproduce it?

Also, please, try on recent daily build, 2016.2972.