Problems with masks

Solar2D General Questions/Discussion
#1

I have been testing out my latest creation. I am using masks for the first time. On the simulator, everything looks and behaves normal. On both my iPhone 3gs and my 5, I experience no problems too; however, on all iPad devices (iPad 1 and 3) I experience a LOT of lag.

The game Im making is a simple puzzle app. The mask covers the image so only the portion of the piece that is needed is shown. The images xScale and yScale are set to .25 to begin with. There is no lag initially on the iPad, but once about 12 pieces are place, the lag becomes very noticeable. The pieces are set to full size and then remain on the screen until you go back to the title screen.

I’ve attempted to reduce the file size of the pieces as I thought it could be related to using to much memory, but it had no impact on the lag.

My biggest hang up is that it works in the simulator, on an iPhone 3gs and on a 5, but not on any iPad. This does not seem to be memory related (especially since reducing file size had no impact and also there is nothing new loaded as the pieces are placed and no lag initially).

The previous puzzle app I made which uses almost identical code (aside from the masking and some settings) experienced no lag and used more memory.

Any ideas?

Thanks,
Scott [import]uid: 79834 topic_id: 33484 reply_id: 333484[/import]

#2

That’s pretty bizarre. The iPad 1 and 3Gs should have very similar performance characteristics given they have the same memory (though the iPad 1 has a faster CPU). I can’t think of anything specific that would be iPad related. I’ll forward this to the team and see if they have any ideas.

Rob
[import]uid: 199310 topic_id: 33484 reply_id: 133070[/import]

#3

It’s hard to tell what’s going on without seeing the project code along with the assets but I would think it’s image size related. Setting the xScale and yScale doesn’t change the size of the image loaded, only how it’s displayed. If you load a large image on a smaller device, the image is scaled down to fit the device, hence a smaller image to move around. Dynamic scaling also enters into the equation.

[import]uid: 7559 topic_id: 33484 reply_id: 133140[/import]

#4

Information regarding the pixel content scaling size (is your virtual screen size 320x480, 640x960,etc) and information about the approximate size of your 12 pieces could be very helpful (are the pieces all 100x100, or range from 300x300 to 750x750, etc). Also, whether they overlap (the bounding rectangles, which would cause a “cascade” redraw of all of them…) could likely affect performance (corona proggie could answer that… I’m curious as to how images are stored in texture memory - ie; at content resolution or expanded to device resolution, and whether masks are stored in texture memory or processed entirely in main memory…)

Regarding file size, that would have no impact on performance (other than load times). All images used for rendering are decompressed in memory. A 10k image on disk that is 512x512 pixel (and each pixel is 1 byte Red, 1 byte green, 1 byte blue, and 1 byte alpha – a standard png), uses 1 MB of texture memory – and it’s mask uses even more memory as well… (I use 512 intentionally, if powers of two texture boundaries look like a factor, we can get into that later…)

As alluded to in the above posts, these factors can make a significant impact on both texture memory and performance. In the iPad 1 case, it may be bound by CPU performance. In the ipad3 case, possibly by memory bandwidth ( 12 times all of screen memory + 12 times all the mask memory, plus all the CPU bandwidth to map onto it).

The ipad 3 can be tricky… Updating large portions of the screen means a lot of data needs to be pushed around… If either of these issues (CPU bound, or memory bound) are the case, there’s steps you can take to work around them. But of course, before you could properly deal with it, you’ve got to understand what the issue is… In that vein…

What is your virtual screen size? What content size (approx width and height) are these 12 pieces? Do the “bounding rectangles” of the pieces overlap? [import]uid: 79933 topic_id: 33484 reply_id: 133162[/import]

#5

The virtual screen size is: 320x480
content = {
width = 320,
height = 480,
scale = “letterBox”,
fps = 30,

So I am using the whole puzzle image and it is: 385x320. @2x - 770x640 @4x - 1540x1280
The Mask Images are 388x320 with no @2x @4x images
(I realize that they are a slightly different size now. Not sure if that would cause the problem?)

On the 24 piece puzzle it uses 24 different masks. All images are loaded and masked at the start.

All images are scaled down to .3 to begin with.

12 images can be seen on the screen, the other 12 have their alpha set to 0.

There is no lag scene on either the iphone 5 or 3gs that I tested on.

On both the iPad 1 and 3 there is a large amount of slowing that occurs.

On the iPad 3, this is not seen until ~ 12 pieces are placed on the screen.

Once placed, the images completely overlap, but the actual visual (unmasked portions) do not.

What I’ve tried: 1) I switched from pngs to jpg for the full puzzle image that is masked. This significantly reduced the size of the full puzzle image. From what I could tell, this had no impact on reducing the slowing that occurs. 2) I removed the @4x image all together and had the same result. 3) Remove the partical effects that occur after the pieces are placed, same result.

Thanks for taking the time to look at this! I can add lines of code if you need.

Scott

[import]uid: 79834 topic_id: 33484 reply_id: 133170[/import]

#6

Can you post your entire config.lua?
[import]uid: 199310 topic_id: 33484 reply_id: 133200[/import]

#7

@Scott - That’s good info, on the ipad3 it sounds like your app is processing a fairly large amount of memory all at once (each screen refresh when a piece moves)… One thing you didn’t mention was the size range of the actual 12 pieces (and whether there are @2, @4 versions).

If the pieces are also large, that could be the issue. (I’d guess they are in the 388x320 ballpark?) If they are essentially full screen (content space), you might want to reconsider your placement scheme (if this is the case, your scheme sounds like the correct positions for all pieces would be the same x,y point, with a lot of empty space per piece right?) You might need to use an alternate scheme to enable smaller pieces (non-full screen pieces) where you store the final/correct points for each piece, and check it when the user drops the piece…

You mentioned they are scaled to 0.3 to start. They are eventually scaled to 1.0, correct? (Wondering if it’s possible to use smaller pieces, or you need to scale them up and down)

Also, not sure how corona optimizes alpha = 0, but I am sure isVisible is optimized out of the render efficiently. Can you set isVisible = false (as opposed to alpha = 0)? [import]uid: 79933 topic_id: 33484 reply_id: 133230[/import]

#8

That’s pretty bizarre. The iPad 1 and 3Gs should have very similar performance characteristics given they have the same memory (though the iPad 1 has a faster CPU). I can’t think of anything specific that would be iPad related. I’ll forward this to the team and see if they have any ideas.

Rob
[import]uid: 199310 topic_id: 33484 reply_id: 133070[/import]

#9

Here is the full config.lua:

application =   
{  
 launchPad = false,  
  
 content = {  
 width = 320,  
 height = 480,   
 scale = "letterBox",  
 fps = 30,  
  
  
 imageSuffix = {  
 ["@2x"] = 2,  
 ["@4x"] = 4,  
 },  
  
 },  
}

the whole puzzle image and it is: 385x320. @2x - 770x640 @4x - 1540x1280 and that is what I am masking. Again though, I removed the @4x image and reduced the file size of the @2x image from 514kb to 79.5kb and saw no performance improvements.

The mask file size always stays 388x320. The mask files are less than 7kb.

I really would not like to break it up if there is another way around it. I eventually am going to make a puzzle app that would need to be able to mask the whole image but the piece to work properly and this project is really just a stepping stone to that.

They go from .3 to 1.0. They are .3 on the screen to start to save space. They are scaled up to 1.0 when touched and then remain at 1.0 when placed in the correct spot on the puzzle.

I could try changing it to isVisible = false for those that are not used at first, but eventually all would be visible by the end of the puzzle.

Here is an example of the code I am using to setup the first piece of a puzzle. There are several variables as things change when different numbers of pieces are being used:

fullpuzxref[1] = -150  
fullpuzyref[1] = -130  
piecesmask[1] = graphics.newMask( "24p1.png" )  
piecescale = .3  
  
fullpuz[1] = display.newImageRect( "puz1top.jpg", 385, 320 )  
fullpuz[1].xReference = fullpuzxref[1]  
fullpuz[1].yReference = fullpuzyref[1]  
fullpuz[1]:setMask( piecesmask[1] )  
fullpuz[1].isHitTestMasked = true  
fullpuz[1].xScale = piecescale  
fullpuz[1].yScale = piecescale  
fullpuz[1].picked = false

Again, no lag in simulator or iPhones (the two I have to test on at least), but on both iPad 3 and 1.

It definitely could be related to something else in my code, but I would expect to see lag on the 3gs if this was the case.

Thanks so much for your help guys!

Scott [import]uid: 79834 topic_id: 33484 reply_id: 133250[/import]

#10

A few comments about your images and some things to try.

  1. Both PNG and JPG images consume the same amount of texture memory when loaded. JPGs take up less room in the App package but are expanded to full size (width x height x 4 bytes) when loaded.

  2. Images are rounded up to the next power of two. So a 320 x 480 image is 153,600 pixels. With four bytes for RGBA, the total image size is 614, 400 bytes. Rounding to the next power of 2, that means it consumes 1 Mbyte of texture memory.

  3. It’s best to make your images an even size if you try to perform any math on height or width. Your 385 x 320 should be 386 x 320 to avoid display issues. Also, watch out for factional values when computing x and y values (round up or down to nearest integer).

  4. Scaling down an image (using xScale and yScale) doesn’t reduce the texture memory size.

  5. If you use @2x & @4x images, you will be loading much larger images on higher resolution devices and I would expect the performance to be worst. My suggestion is to remove all @2x and @4x images and see if the performance of iPad1 and iPad3 matches that of the iPhone 3g and 5.

  6. Try disabling the masks and see if that makes a difference in performance.

If the results in #5 don’t improve (using the same image sizes for all devices) or disabling masks (#6) improves the performance, please file a bug report with a test case that reproduces the problem. [import]uid: 7559 topic_id: 33484 reply_id: 133255[/import]

#11

@scott, you said “the whole puzzle image and it is”… I don’t understand… Does that mean you have no separate puzzle pieces, and use 12 masks on your main image to manipulate pieces (which are shaped like the mask)?

Tom had a lot of pointed notes… Lemme add some other observations–

Like Tom said, the file size on disk is unrelated to performance (as you’ve seen).

Objects are decompressed when they are loaded – and the memory they take is equal to 4 x (width x height) bytes. Your full screen @4x image takes up 16MB of memory on the ipad3.

Each time that image is redrawn (which could be 12 times, if you have 12 pieces all referencing the same full screen image), the device needs to push 16MB of memory to the screen, plus more – for all the objects on top of it…

If there’s 12 pieces being rendered on top, and all are (even copies) of the 16MB image… (12x16MB being masked and processed) it just might not be able to do it at 30 frames per second… Still can’t quite tell if that’s what your doing though…

As an aside, I thought iPad 1 support was dropped when ios6 support was added (and 2nd gen ipods, and 3g support was dropped too, although 3gs is still officially supported I believe). [import]uid: 79933 topic_id: 33484 reply_id: 133257[/import]

#12

@mpappas, iPad 1 is not supported on iOS 6, but is supported on iOS 5.1.1. iPhone 3gs supports iOS 6. Both devices are still supported in Corona. iPhone 3g is not. [import]uid: 7559 topic_id: 33484 reply_id: 133259[/import]

#13

@Tom - ahh, thanks for the info! I thought the iPad 1 didn’t support 5.1, so was dropped. Good to know my app will run on them. [import]uid: 79933 topic_id: 33484 reply_id: 133260[/import]

#14

Trying out some of the things you said. Will report in in a little bit. In the mean time I am adding a screen shot of the puzzle so my explanation makes more sense:

https://lh3.googleusercontent.com/-Tz0RIptx6_Y/ULqKJ2zZ23I/AAAAAAAAAWI/5l0E_jhJAO8/s720/sreen1.jpg

There are 24 total masked images (the 24 pieces)
All pieces begin loaded and masked, just some are not visible.
Once twelve pieces are in place, the lag begins (pieces move slower when dragged, particle effects slow down, etc), but only on iPad devices. [import]uid: 79834 topic_id: 33484 reply_id: 133282[/import]

#15

It’s hard to tell what’s going on without seeing the project code along with the assets but I would think it’s image size related. Setting the xScale and yScale doesn’t change the size of the image loaded, only how it’s displayed. If you load a large image on a smaller device, the image is scaled down to fit the device, hence a smaller image to move around. Dynamic scaling also enters into the equation.

[import]uid: 7559 topic_id: 33484 reply_id: 133140[/import]

#16

Information regarding the pixel content scaling size (is your virtual screen size 320x480, 640x960,etc) and information about the approximate size of your 12 pieces could be very helpful (are the pieces all 100x100, or range from 300x300 to 750x750, etc). Also, whether they overlap (the bounding rectangles, which would cause a “cascade” redraw of all of them…) could likely affect performance (corona proggie could answer that… I’m curious as to how images are stored in texture memory - ie; at content resolution or expanded to device resolution, and whether masks are stored in texture memory or processed entirely in main memory…)

Regarding file size, that would have no impact on performance (other than load times). All images used for rendering are decompressed in memory. A 10k image on disk that is 512x512 pixel (and each pixel is 1 byte Red, 1 byte green, 1 byte blue, and 1 byte alpha – a standard png), uses 1 MB of texture memory – and it’s mask uses even more memory as well… (I use 512 intentionally, if powers of two texture boundaries look like a factor, we can get into that later…)

As alluded to in the above posts, these factors can make a significant impact on both texture memory and performance. In the iPad 1 case, it may be bound by CPU performance. In the ipad3 case, possibly by memory bandwidth ( 12 times all of screen memory + 12 times all the mask memory, plus all the CPU bandwidth to map onto it).

The ipad 3 can be tricky… Updating large portions of the screen means a lot of data needs to be pushed around… If either of these issues (CPU bound, or memory bound) are the case, there’s steps you can take to work around them. But of course, before you could properly deal with it, you’ve got to understand what the issue is… In that vein…

What is your virtual screen size? What content size (approx width and height) are these 12 pieces? Do the “bounding rectangles” of the pieces overlap? [import]uid: 79933 topic_id: 33484 reply_id: 133162[/import]

#17

The virtual screen size is: 320x480
content = {
width = 320,
height = 480,
scale = “letterBox”,
fps = 30,

So I am using the whole puzzle image and it is: 385x320. @2x - 770x640 @4x - 1540x1280
The Mask Images are 388x320 with no @2x @4x images
(I realize that they are a slightly different size now. Not sure if that would cause the problem?)

On the 24 piece puzzle it uses 24 different masks. All images are loaded and masked at the start.

All images are scaled down to .3 to begin with.

12 images can be seen on the screen, the other 12 have their alpha set to 0.

There is no lag scene on either the iphone 5 or 3gs that I tested on.

On both the iPad 1 and 3 there is a large amount of slowing that occurs.

On the iPad 3, this is not seen until ~ 12 pieces are placed on the screen.

Once placed, the images completely overlap, but the actual visual (unmasked portions) do not.

What I’ve tried: 1) I switched from pngs to jpg for the full puzzle image that is masked. This significantly reduced the size of the full puzzle image. From what I could tell, this had no impact on reducing the slowing that occurs. 2) I removed the @4x image all together and had the same result. 3) Remove the partical effects that occur after the pieces are placed, same result.

Thanks for taking the time to look at this! I can add lines of code if you need.

Scott

[import]uid: 79834 topic_id: 33484 reply_id: 133170[/import]

#18

Can you post your entire config.lua?
[import]uid: 199310 topic_id: 33484 reply_id: 133200[/import]

#19

Okay! Reporting back in.

Things I tried that didnt make a difference:

Removing the @2x and @4x -
Resulted in similar performance and looked real bad :slight_smile:

Puzzle images now match the mask size:
388x320 and multiples there of for @2x and 4x

Setting it to isVisible as opposed to Alpha of 0:
Did not make a difference.

Altered the code to reduce any extra things going on:
No improvements

Things that improved performance:

Removing All Masks and leaving @4x and @2x in the build:
No slowing at all

When the puzzle is completed, there is an animation sequence. Before I just reinserted the animated images so they were on top. I made it now so all the puzzle piece images were set to .isVisible = false. This instantly restores the performance and the animation runs smooth even when masks are being used.

So, it is definitely related to the masked images.

I will add an image what my masks look like to make sure I am making them correctly. Maybe something with my mask is causing odd effects.
[import]uid: 79834 topic_id: 33484 reply_id: 133376[/import]

#20

Couple more experiments-
All pieces full size and visible the whole time: Still no lag to begin with, but starts getting noticeable at about 4 pieces in place as opposed to 12 pieces.

All pieces at .3 (xScale,yScale) and visible the whole time: NO LAG at all! Now at .3 it looks silly as the tiny pieces just sit inside the full size pieces shadow.

So it appears that the problem has something to do with the display size of the pieces when masked and visible. Perhaps it is an issue with multiple pieces overlapping each other?
[import]uid: 79834 topic_id: 33484 reply_id: 133380[/import]