Using captureScreen image as BitmapPaint?

The syntax for BitmapPaint references images from files:

local paint = { type = "image", filename = , baseDir = }

How can display.captureScreen() be used as BitmapPaint for an object.fill?

Saving a screen capture to file and then using that is a slooow work-around btw.

The end use for this is applying 2.5D effects to the screen during a Composer transition. But two of the same image will be required so bitmapPaint is useful here to avoid multiple objects of the same image in memory…

Hi @kilopop,

I’m not sure I understand why you need to save this to a file. If you only need two “copies” of the screen, just use the capture screen API twice in succession and use those two display objects for the scene transition (no need to save them to a local file). Yes, there would be two textures in memory, but I assume these captures wouldn’t be persistently stored, so texture memory wouldn’t be a major issue, correct? Perhaps I’m not fully understanding your necessity in this, however.

Brent

Hi Brent,

So, each screenCapture takes up 11mb of texture memory. Adding 22mb to full Retina screens that are already high isn’t ideal, especially in this use case as Composer transition images where the next scene is concurrently in texture memory…

I may try some work-arounds bringing scene disposal forward after the first screen grab, unless there are any other ideas out there?

Hi @kilopop,

I’m not sure I understand why you need to save this to a file. If you only need two “copies” of the screen, just use the capture screen API twice in succession and use those two display objects for the scene transition (no need to save them to a local file). Yes, there would be two textures in memory, but I assume these captures wouldn’t be persistently stored, so texture memory wouldn’t be a major issue, correct? Perhaps I’m not fully understanding your necessity in this, however.

Brent

Hi Brent,

So, each screenCapture takes up 11mb of texture memory. Adding 22mb to full Retina screens that are already high isn’t ideal, especially in this use case as Composer transition images where the next scene is concurrently in texture memory…

I may try some work-arounds bringing scene disposal forward after the first screen grab, unless there are any other ideas out there?