GuiChunkedBitmapCtrl vs guiBitmapCtrl
by Orion Elenzil · in Torque Game Engine · 09/05/2008 (2:21 pm) · 6 replies
What's the skinny on the differences between these two ?
3DGPAIO says that guiChunkedBitmapCtrl is generally used for large controls (eg a login screen or similar) because it gets a performance boost by chunking the bitmap up into smaller pieces.
.. which seems pretty cool!
why would i not want to use that all the time ?
also,
looking at the code, (TGE 1.3 -based)
i think you would need to set "tile=true" to get any effect.
finally,
are the performance benefits really significant enough to warrant using this over good old familiar GuiBitmapCtrl ? especially on a login screen, i'm not so concerned about FPS, and it's going to be blazing anyhow.
tia!
ooo
3DGPAIO says that guiChunkedBitmapCtrl is generally used for large controls (eg a login screen or similar) because it gets a performance boost by chunking the bitmap up into smaller pieces.
.. which seems pretty cool!
why would i not want to use that all the time ?
also,
looking at the code, (TGE 1.3 -based)
i think you would need to set "tile=true" to get any effect.
finally,
are the performance benefits really significant enough to warrant using this over good old familiar GuiBitmapCtrl ? especially on a login screen, i'm not so concerned about FPS, and it's going to be blazing anyhow.
tia!
ooo
About the author
#2
However, that said, guiBitmapCtrl only uses one texture to store the image. The larger the image gets, the more memory is required. "Duh" you say, but here's my point: If you have an image size that is not a power of 2, the texture size still must be a power of 2, thus it must choose the next larger size. For example, if your image happens to be 1080 x 700, the actual texture size must be 2048 x 1024! I'm not gonna do the math, but clearly a lot of video memory is getting wasted.
guiChunkedBitmapCtrl mitigates this by breaking the image down into 256x256 chunks (like William mentioned; see the ChunkedTextureManager for the nitty-gritty...). So to re-use the example above, 1080 x 700 now fits into a total texture size of 1280 x 768; far less video memory wasted.
So, to summarize, guiChunkedBitmapCtrl doesn't really improve rendering speed (if anything, it's prolly somewhat slower), but it can have a huge impact on texture memory usage.
09/11/2008 (4:01 pm)
At some point in the past, I believe that guiBitmapCtrl had a size cap of 256x256, but this doesn't appear to be the case any longer. Performance-wise, I've never seen any appreciable difference between the two, and I generally stick with guiBitmapCtrl.However, that said, guiBitmapCtrl only uses one texture to store the image. The larger the image gets, the more memory is required. "Duh" you say, but here's my point: If you have an image size that is not a power of 2, the texture size still must be a power of 2, thus it must choose the next larger size. For example, if your image happens to be 1080 x 700, the actual texture size must be 2048 x 1024! I'm not gonna do the math, but clearly a lot of video memory is getting wasted.
guiChunkedBitmapCtrl mitigates this by breaking the image down into 256x256 chunks (like William mentioned; see the ChunkedTextureManager for the nitty-gritty...). So to re-use the example above, 1080 x 700 now fits into a total texture size of 1280 x 768; far less video memory wasted.
So, to summarize, guiChunkedBitmapCtrl doesn't really improve rendering speed (if anything, it's prolly somewhat slower), but it can have a huge impact on texture memory usage.
#3
sure seems like that kind of chunking would be a nice thing for the video driver/hardware to do, don't it ?
09/11/2008 (4:21 pm)
Great explanation, thanks Kevin!sure seems like that kind of chunking would be a nice thing for the video driver/hardware to do, don't it ?
#4
09/11/2008 (6:03 pm)
Well, it's really an old solution to an old problem. Current hardware/drivers (e.g. DirectX 10 level) allow for arbitrary texture sizes. But since Torque has to deal with older hardware (and via an older API), the powers of 2 texture size must still be enforced. =\ 
#5
I was under the impression that GuiChunkedBitmapCtrl's purpose was to break up textures into chunks so you could avoid texture size limits on older hardware. Ie on Geforce 2-3 class hardware the maximum texture width was somewhere around 768-1024 pixels and that wasn't always practical when you wanted high res backgrounds.
Just my guess, though.
09/12/2008 (6:21 pm)
AFAIK you want to avoid swapping textures if you can stuff them all into one large bitmap. Hence why some engines use texture atlases. So can't see why that would be the reason for this control.I was under the impression that GuiChunkedBitmapCtrl's purpose was to break up textures into chunks so you could avoid texture size limits on older hardware. Ie on Geforce 2-3 class hardware the maximum texture width was somewhere around 768-1024 pixels and that wasn't always practical when you wanted high res backgrounds.
Just my guess, though.
#6
Regarding texture atlases: That's pretty much the opposite of what this control does... With an atlas, you're taking multiple smaller images and fitting them into one larger texture. But I'm going to assume that this process is still optimized to fit the images into the texture space wtih a minimum of wasted memory as well, much like this control does.
09/19/2008 (2:01 am)
@Stefan: Yes, good point... I spaced that there were the max texture size limitations on the really old hardware. (e.g. only 256 for the early, early cards like 3dfx Voodoo). And the guiChunkedBitmapCtrl would solve that problem as well.Regarding texture atlases: That's pretty much the opposite of what this control does... With an atlas, you're taking multiple smaller images and fitting them into one larger texture. But I'm going to assume that this process is still optimized to fit the images into the texture space wtih a minimum of wasted memory as well, much like this control does.
Associate William Lee Sims
Machine Code Games
As for performance, I've never tested it, but I can imagine that for texturing reasons, you'll get a boost out of using the smaller regions instead of one enormous texture. (That is a WILD guess, though.)