[FIXED] display.captureBounds bug?

Develephant · October 13, 2013, 11:45am

I was pulling my hair out trying to figure out a capture issue when it occurred to me to check it in the daily. Sure enough it works fine in the daily, but not Graphics 2.0 beta.

Code:

[lua]
local d = display.newImage( “gfx/photo.jpg” )

local xScale = display.contentWidth / d.contentWidth

local yScale = display.contentHeight / d.contentHeight

local scale = math.max( xScale, yScale )

d:scale( scale, scale )

d.x = display.contentCenterX

d.y = display.contentCenterY

local _c = display.captureBounds( d.contentBounds, true )

[/lua]

zoomEven : Graphics 2.0

Result:

zoomEven : Build 2013.1233

Result:

Now, interestingly enough, the file that saves from the G2.0 version is a much nicer resolution ( I scaled the attached image 50% so I could upload it to the forum ) but it is being visually “cropped” as shown.

The other image from the daily build comes out at a much lower resolution, but outputs correctly.

What would be great is that nice high res from the G2 version, but fitting correctly.

Any suggestions? Or is this something that needs to be addressed?

Thanks in advance.

RedBeach · October 25, 2013, 11:55pm

Hi develephant.

Thanks for posting that info. Have you already submitted that bug for Corona?

rob · October 26, 2013, 2:39am

Please submit a bug report. Use the “Report a bug” feature at the top right of the page.

Fat_Red_Couch · October 31, 2013, 1:10am

Also, I don’t believe display.captureBounds() works on device at the moment (display.capture is listed as a “known issue” on device for gfx 2.0).

Any estimate as to when the display.captureBounds() API will work on device for gfx 2.0 builds?

rob · October 31, 2013, 1:57am

Some of this is still a work in progress. Engineering needs to know about these which is why we ask for the bug reports.

Thanks

Rob

Develephant · October 31, 2013, 4:30am

I have submitted the bug a couple of days ago, fyi.

jen.looper · November 5, 2013, 2:20am

I’m trying to figure out display.captureScreen(). For some reason this code snippet:

local screenCap = display.captureScreen()

local baseDir = system.TemporaryDirectory

display.save( screenCap, “photo.jpg”, baseDir )

screenCap:removeSelf()

screenCap = nil

just saves about 1/4 of the screen to my tempDir. Help? Using graphics 2.0 Build: 2013.2035

Joshua_Quick · November 5, 2013, 2:51am

I see one problem with your code. It is capturing the screen twice. The display.save() function that you’re calling is effectively capturing the “screen capture”. This is a performance issue and will take twice as much memory… which would be very noticeable on an iPad retina. A better solution would be the following, which should also work-around the bug that you’ve found…

local baseDir = system.TemporaryDirectory display.save( display.currentStage, "photo.jpg", baseDir )

Have a look at sample project “Storage/ScreenCaptureToFile” that is included with the Corona Simulator for an example of this. It captures the screen as shown above and then displays it on screen.

That said, you’ve probably found a legitimate bug. I haven’t tried it for myself yet, but I’m guessing that when you do the display.captureScreen() call, the capture image that is shown on screen is bigger than the content that was actually captured. Right? You can prove this by commenting out the removeSelf() part in your code.

jen.looper · November 5, 2013, 3:02am

Yes! That did create a nice workaround, one step closer to my contest submission, mua ha ha …

With regards to the other issue, yes, you’re right, with just a display.captureScreen() call, only the bottom 1/4th of the screen is saved. I was also throwing some strange errors when experimenting with captureBounds:

Corona Simulator(47094,0x7fff7761c310) malloc: *** mach_vm_map(size=18446737476639784960) failed (error code=3)

*** error: can’t allocate region

*** set a breakpoint in malloc_error_break to debug

capture bounds in content units: x: -2147483648 y: -384 w: -2147483648 h: 360

capture bounds in pixels: x: 0 y: 0 w: -2147483648 h: 768

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: CGImageCreate: unsupported image width: 2147483648.

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: Unsupported dimensions - 0 x, 0 y, 2147483648 width, 768 height, 8589934592 bytes-per-row

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: CGBitmapContextCreateWithData: failed to create delegate.

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: CGContextDrawImage: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: CGBitmapContextCreateImage: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: ImageIO: CGImageDestinationAddImage image parameter is nil

Nov 4 21:08:20 Administrators-MacBook-Pro-2.local Corona Simulator[47094] <Error>: ImageIO: CGImageDestinationFinalize image destination must have at least one image

albert90 · November 6, 2013, 10:48pm

The behavior of display.captureBounds() should be correct in the next Graphics 2.0 daily build. Please let us know if you have any further problems. Thanks!

RedBeach · November 6, 2013, 10:49pm

Nice. Thanks Albert

jen.looper · November 6, 2013, 11:29pm

awesome, thanks!

RedBeach · October 25, 2013, 11:55pm