How I get text texture size?

[stan8]

I noticed today that my app crashes on some devices, but not on others…

When trying to debug the crash, I noticed it happened in a “newText” line…

Not only that, the reason for the crash was a problem with the memory.
I don’t know, if the crash is because the memory use was too large in KB, or because the texture generated was too big (like being 23808902734 pixels tall or something).

I am trying to do some testing, but without knowing how newText works, is hard…

So, newText seemly creates a texture in the memory and paste it on a OpenGL quad or something like that.

So:

First, using a group (like, two texts), generates a bigger texture or put two textures in the same quad?

Second, how I get the texture size actually generated in the memory in pixels?

Third, the “height” of the generated text is always in the basic logic coordinates?

Fourth, the texture generation takes account the multiplier you defined? (example, if it is running in @2 it creates 0.77777 always if you defined that it is 0.7777 or in some devices it might be 0.5, or 0.6 or 0.321 or whatever) [import]uid: 142895 topic_id: 31419 reply_id: 331419[/import]

[mpappas]

I found this in the code exchange:

-- performance.lua   
--  
-- Shows mem usage for diagnostics.   
--  
--  
  
local \_M = {}  
   
local mFloor = math.floor  
local sGetInfo = system.getInfo  
local sGetTimer = system.getTimer  
   
local prevTime = 0  
\_M.added = true  
local function createText()  
 local memory = display.newText('00 00.00 000',10,0, 'Helvetica', 20);  
 memory:setReferencePoint(display.TopCenterReferencePoint)  
 memory.x, memory.y = display.contentCenterX, display.screenOriginY  
 function memory:tap ()  
 collectgarbage('collect')  
 if \_M.added then  
 Runtime:removeEventListener('enterFrame', \_M.labelUpdater)  
 \_M.added = false  
 else  
 Runtime:addEventListener('enterFrame', \_M.labelUpdater)  
 \_M.added = true  
 end  
 end  
 memory:addEventListener('tap', memory)  
 return memory  
end  
   
function \_M.labelUpdater(event)  
 local curTime = sGetTimer()  
 \_M.text.text = tostring(mFloor( 1000 / (curTime - prevTime))) .. ' ' ..  
 tostring(mFloor(sGetInfo('textureMemoryUsed') \* 0.0001) \* 0.01) .. ' ' ..  
 tostring(mFloor(collectgarbage('count')))  
 \_M.text:toFront()  
 prevTime = curTime  
end  
   
function \_M:newPerformanceMeter()  
 self.text = createText(self)  
 Runtime:addEventListener('enterFrame', \_M.labelUpdater)  
end  
   
return \_M  

Then, in your main, add:

-- Performance meter  
local performance = require('performance')  

And a little performance meter showing your FPS, texture mem use, and overall system mem use will be displayed at the top of the screen while running the app… For details, lookup the performance meter in the code exchange… (lots of nice tidbits in that exchange!) [import]uid: 79933 topic_id: 31419 reply_id: 125598[/import]

[stan8]

Just to clarify: I am not asking for that…

I am asking for:

First, using a group (like, two texts), generates a bigger texture or put two textures in the same quad?

Second, how I get the texture size actually generated in the memory in pixels?

Third, the “height” of the generated text is always in the basic logic coordinates?

Fourth, the texture generation takes account the multiplier you defined? (example, if it is running in @2 it creates 0.77777 always if you defined that it is 0.7777 or in some devices it might be 0.5, or 0.6 or 0.321 or whatever) [import]uid: 142895 topic_id: 31419 reply_id: 125610[/import]

[mpappas]

As far as I know, and watching memory with tools like above, textures work like the following:

• You load an image, it is 9 pixels by 9 pixels.
• The SDK converts it to texture memory, regardless of the original image format.
• Converting to texture memory exapnds the image to 3 bytes per pixel, and upsizes the width and height to the nearest power of 2.

So a two bit per pixel, 9x9 size image is converted to 3 bytes per pixel, size 16x16.

For full screen 640x960 images, both sizes are upsized to 1024x1024 in texture memory, at 3 bytes per pixel… Taking 3 MB per image. It adds up quick, and tools like above can help you to sort it out on your particular devices. Having @2x or not in the name does NOT play a factor – the sizes are based on the actual image size no matter what the filename is (if it’s a @2x, and it’s bigger, then that is what is allocated for - it’s based on the actual loaded image size no matter the way it is named). So yah, using @2x affects texture memory, but not because of the filename – it’s only because the images themselves that end up loaded are bigger.

These calculations have worked for me, and to maintain compatability across a lot of devices, I’m limiting my apps max texture use to 24MB. Good luck. [import]uid: 79933 topic_id: 31419 reply_id: 125611[/import]

[stan8]

No dude…

I need to know the dimensions in pixels of the generated texture of display.newText so I can calculate how much text I can put on the memory. [import]uid: 142895 topic_id: 31419 reply_id: 125618[/import]

[stan8]

I am using the widget that scrolls…

The text is a scrolling text.

Also noone yet replied to me the relation between the width and height of the displayObject and the pixel size in the texture memory. [import]uid: 142895 topic_id: 31419 reply_id: 125622[/import]

[mpappas]

You are generating that much text at once that it fills memory??

I’m pretty sure it can’t fit on screen and be readable all at once… I think a much better strategy would be to generate it on the fly, as needed (and remove the old text).

the tableView object does “lazy loading” of cells, freeing up the old objects/text as they scroll offscreen, and creating / loading the new rows as they slide onscreen (the onRowRender routine does it)- it manages it all, and can support thousands and thousands of lines of text.

I’d suggest instead of trying to ascertain exactly how it packs thousands of text objects, you reduce the objects to a screens worth (at a time)…

NOTE: If you just access the text width and height, that is most likely the generated size… Corona also spits out messages on my console when it changes the size (ie: a message on the console saying "WARNING: Due to system limitations, displaynewText() width is going to be increased to nearest multiple of 4: 22===>24) [import]uid: 79933 topic_id: 31419 reply_id: 125621[/import]

[mpappas]

I’m not doing a lot of this stuff, but if I was, I would expect a couple factors affect the text size (.width and .height) and it’s relation to actual device pixel size, most notably your content scaling…

Text generated in your app is sized to your content scaling scheme… So the values for width and height are converted to your scaling scheme and may not be real device pixel sizes (and thus the actual texture sizes).

To calculate the real texture sizes, I would imaging you would need to multiply the sizes by your scaling factor…

ie; if your scaling makes your app use 320x480 app coords, but the device it is running on is 640x960… Your app will say the text width height is, say, 100x16… But because of your scaling, the true device coords size would be 200x32…

That would be my guess… Best of luck. [import]uid: 79933 topic_id: 31419 reply_id: 125625[/import]

[mpappas]

I found this in the code exchange:

-- performance.lua   
--  
-- Shows mem usage for diagnostics.   
--  
--  
  
local \_M = {}  
   
local mFloor = math.floor  
local sGetInfo = system.getInfo  
local sGetTimer = system.getTimer  
   
local prevTime = 0  
\_M.added = true  
local function createText()  
 local memory = display.newText('00 00.00 000',10,0, 'Helvetica', 20);  
 memory:setReferencePoint(display.TopCenterReferencePoint)  
 memory.x, memory.y = display.contentCenterX, display.screenOriginY  
 function memory:tap ()  
 collectgarbage('collect')  
 if \_M.added then  
 Runtime:removeEventListener('enterFrame', \_M.labelUpdater)  
 \_M.added = false  
 else  
 Runtime:addEventListener('enterFrame', \_M.labelUpdater)  
 \_M.added = true  
 end  
 end  
 memory:addEventListener('tap', memory)  
 return memory  
end  
   
function \_M.labelUpdater(event)  
 local curTime = sGetTimer()  
 \_M.text.text = tostring(mFloor( 1000 / (curTime - prevTime))) .. ' ' ..  
 tostring(mFloor(sGetInfo('textureMemoryUsed') \* 0.0001) \* 0.01) .. ' ' ..  
 tostring(mFloor(collectgarbage('count')))  
 \_M.text:toFront()  
 prevTime = curTime  
end  
   
function \_M:newPerformanceMeter()  
 self.text = createText(self)  
 Runtime:addEventListener('enterFrame', \_M.labelUpdater)  
end  
   
return \_M  

Then, in your main, add:

-- Performance meter  
local performance = require('performance')  

And a little performance meter showing your FPS, texture mem use, and overall system mem use will be displayed at the top of the screen while running the app… For details, lookup the performance meter in the code exchange… (lots of nice tidbits in that exchange!) [import]uid: 79933 topic_id: 31419 reply_id: 125598[/import]

[stan8]

Just to clarify: I am not asking for that…

I am asking for:

First, using a group (like, two texts), generates a bigger texture or put two textures in the same quad?

Second, how I get the texture size actually generated in the memory in pixels?

Third, the “height” of the generated text is always in the basic logic coordinates?

Fourth, the texture generation takes account the multiplier you defined? (example, if it is running in @2 it creates 0.77777 always if you defined that it is 0.7777 or in some devices it might be 0.5, or 0.6 or 0.321 or whatever) [import]uid: 142895 topic_id: 31419 reply_id: 125610[/import]

[mpappas]

As far as I know, and watching memory with tools like above, textures work like the following:

• You load an image, it is 9 pixels by 9 pixels.
• The SDK converts it to texture memory, regardless of the original image format.
• Converting to texture memory exapnds the image to 3 bytes per pixel, and upsizes the width and height to the nearest power of 2.

So a two bit per pixel, 9x9 size image is converted to 3 bytes per pixel, size 16x16.

For full screen 640x960 images, both sizes are upsized to 1024x1024 in texture memory, at 3 bytes per pixel… Taking 3 MB per image. It adds up quick, and tools like above can help you to sort it out on your particular devices. Having @2x or not in the name does NOT play a factor – the sizes are based on the actual image size no matter what the filename is (if it’s a @2x, and it’s bigger, then that is what is allocated for - it’s based on the actual loaded image size no matter the way it is named). So yah, using @2x affects texture memory, but not because of the filename – it’s only because the images themselves that end up loaded are bigger.

These calculations have worked for me, and to maintain compatability across a lot of devices, I’m limiting my apps max texture use to 24MB. Good luck. [import]uid: 79933 topic_id: 31419 reply_id: 125611[/import]

[stan8]

No dude…

I need to know the dimensions in pixels of the generated texture of display.newText so I can calculate how much text I can put on the memory. [import]uid: 142895 topic_id: 31419 reply_id: 125618[/import]

[stan8]

I am using the widget that scrolls…

The text is a scrolling text.

Also noone yet replied to me the relation between the width and height of the displayObject and the pixel size in the texture memory. [import]uid: 142895 topic_id: 31419 reply_id: 125622[/import]

[mpappas]

You are generating that much text at once that it fills memory??

I’m pretty sure it can’t fit on screen and be readable all at once… I think a much better strategy would be to generate it on the fly, as needed (and remove the old text).

the tableView object does “lazy loading” of cells, freeing up the old objects/text as they scroll offscreen, and creating / loading the new rows as they slide onscreen (the onRowRender routine does it)- it manages it all, and can support thousands and thousands of lines of text.

I’d suggest instead of trying to ascertain exactly how it packs thousands of text objects, you reduce the objects to a screens worth (at a time)…

NOTE: If you just access the text width and height, that is most likely the generated size… Corona also spits out messages on my console when it changes the size (ie: a message on the console saying "WARNING: Due to system limitations, displaynewText() width is going to be increased to nearest multiple of 4: 22===>24) [import]uid: 79933 topic_id: 31419 reply_id: 125621[/import]

[mpappas]

I’m not doing a lot of this stuff, but if I was, I would expect a couple factors affect the text size (.width and .height) and it’s relation to actual device pixel size, most notably your content scaling…

Text generated in your app is sized to your content scaling scheme… So the values for width and height are converted to your scaling scheme and may not be real device pixel sizes (and thus the actual texture sizes).

To calculate the real texture sizes, I would imaging you would need to multiply the sizes by your scaling factor…

ie; if your scaling makes your app use 320x480 app coords, but the device it is running on is 640x960… Your app will say the text width height is, say, 100x16… But because of your scaling, the true device coords size would be 200x32…

That would be my guess… Best of luck. [import]uid: 79933 topic_id: 31419 reply_id: 125625[/import]