[T3D 1.1 B1] - Slow performance in GuiBitmapButtonCtrl::setBitmap - LOGGED
by Dusty Monk · in Torque 3D Professional · 03/25/2010 (4:53 am) · 10 replies
So after porting over from 1.0.1 alpha to 1.1 beta, something I've noticed is that all my UI refreshes are taking *much* longer. I've narrowed this down to the fact that I do a lot of setBitmap calls to UI elements for things like ability lists & inventory. Now allowing for the fact that many setBitmap calls on UI elements is probably not the most efficient way of doing things, nevertheless in T3D 1.0.1 alpha this was never a problem, and my UI updates were pretty spritely and quick.
Now though, my entire game pauses for close to a second whenever I bring up the inventory as the script runs through all the slots setting bitmaps according to what's in the inventory. I've perused the code in GuiBitmapButtonCtrl, and while the structure has changed somewhat, the underlying functionality is pretty much the same. Go through and create (or look up) the texture handle for each button variation of the button's bitmap (normal, depressed, inactive, highlighted). So given that *that* code hasn't changed much, I can only assume something has changed in the underlying texture management.
So, has anyone else experienced this when going to 1.1? Or can anyone make suggestions on making setBitmap faster? Would it help if my textures were all power of 2 dimensioned? Do I need to specifically create a material definition for each button texture? Is there some way in script I can preload the textures, and just assign the texture handles to the buttons?
Any thoughts, comments, or similar experiences would be greatly appreciated.
Now though, my entire game pauses for close to a second whenever I bring up the inventory as the script runs through all the slots setting bitmaps according to what's in the inventory. I've perused the code in GuiBitmapButtonCtrl, and while the structure has changed somewhat, the underlying functionality is pretty much the same. Go through and create (or look up) the texture handle for each button variation of the button's bitmap (normal, depressed, inactive, highlighted). So given that *that* code hasn't changed much, I can only assume something has changed in the underlying texture management.
So, has anyone else experienced this when going to 1.1? Or can anyone make suggestions on making setBitmap faster? Would it help if my textures were all power of 2 dimensioned? Do I need to specifically create a material definition for each button texture? Is there some way in script I can preload the textures, and just assign the texture handles to the buttons?
Any thoughts, comments, or similar experiences would be greatly appreciated.
About the author
Dusty Monk is founder and president of Windstorm Studios, an independant game studio. Formerly a sr. programmer at Ensemble Studios, Dusty has worked on AAA titles such as Age of Empires II & III, and Halo Wars.
#2
06/10/2010 (7:35 am)
Ted, I never noticed this post before but what you are looking to do has me interested. If you give me some specs I would be willing to try and make an actual control for this. If you look me up you will see that I have done a lot of gui controls already and I have some ideas already on how to do this. 
#3
06/10/2010 (9:07 am)
@Ryan: It's not a matter of making the control (though that would be pretty cool), but it's an issue of performance in using set bitmap, which is used to change bitmaps in GUIs quite a bit. Moving from 1.0.1 to 1.1 changed its performance in a negative direction, so there was some change made there that should be fixed.
#4
06/10/2010 (9:14 am)
@Ted: sorry, I wasn't chiming in on the performance issue which should be addressed. I was just offering to help save you some scripting work on your controls by creating a control with the functionality you need.
#5
btnFoo.bitmap= "buttonimage";
looks for:
buttonimage_n
buttonimage_d
buttonimage_h
buttonimage_i
buttonimage_ctrl_n
buttonimage_ctrl_d
buttonimage_ctrl_h
buttonimage_ctrl_i
buttonimage_alt_n
buttonimage_alt_d
buttonimage_alt_h
buttonimage_alt_i
buttonimage_shift_n
buttonimage_shift_d
buttonimage_shift_h
buttonimage_shift_i
If it can't find any of those images it sets the image index to a null and later will try to use the default image for the state. This search is done everytime a call to setBitmap occurs. I bet that is causeing the slow down. The best way I can think of to handle it to modify the control to allow you to specify what modifiers will be used. That way if you are not using _ctrl, _alt, or _shift then don't look for those images. Do you guys see a lot of console spam about searching for textures when you use this control?
06/10/2010 (4:51 pm)
Just looking into the GuiBitmapButtonCtrl code I noticed that it supports haveing differnet images depending on certain keys that are pressed. There are 4 states and 4 modifiers which mean the control will load references to 16 textures per control. If your not carefull with the size of your image this can get costly very quickly. It looks for images like this:btnFoo.bitmap= "buttonimage";
looks for:
buttonimage_n
buttonimage_d
buttonimage_h
buttonimage_i
buttonimage_ctrl_n
buttonimage_ctrl_d
buttonimage_ctrl_h
buttonimage_ctrl_i
buttonimage_alt_n
buttonimage_alt_d
buttonimage_alt_h
buttonimage_alt_i
buttonimage_shift_n
buttonimage_shift_d
buttonimage_shift_h
buttonimage_shift_i
If it can't find any of those images it sets the image index to a null and later will try to use the default image for the state. This search is done everytime a call to setBitmap occurs. I bet that is causeing the slow down. The best way I can think of to handle it to modify the control to allow you to specify what modifiers will be used. That way if you are not using _ctrl, _alt, or _shift then don't look for those images. Do you guys see a lot of console spam about searching for textures when you use this control?
#6
Actually, I think that would help the entire community if you wanted to go ahead and do that. I would- but that task is so far down the list that it probably wouldn't even make it this year.
As for the console spam- there's none. My control doesn't use the ctrl/shift keys, and you actually don't have to provide them, as only the first four states are really looked for (and even if you don't have those four states, if you specify the extension, it won't look for the states). This is a performance issue within the 1.1 code, which is slower than the 1.0.1 code.
06/10/2010 (7:10 pm)
Quote:I was just offering to help save you some scripting work on your controls by creating a control with the functionality you need.
Actually, I think that would help the entire community if you wanted to go ahead and do that. I would- but that task is so far down the list that it probably wouldn't even make it this year.
As for the console spam- there's none. My control doesn't use the ctrl/shift keys, and you actually don't have to provide them, as only the first four states are really looked for (and even if you don't have those four states, if you specify the extension, it won't look for the states). This is a performance issue within the 1.1 code, which is slower than the 1.0.1 code.
#7
06/11/2010 (9:35 am)
@Ted, when the bitmap is set on the control it attempts to load the full 16 images. It is later in the code when it decides what image to render that it determines if one has been loaded for that state. But no matter what the control will always try to load 16 images. In fact looking at the code for 1.1A it wasn't using any states so it only tried to load the 4 images. I am really supprised that there isn't console spam on the missing images. Try turning on tracing by putting trace(true); in your main.cs and see what you get.
#8
Exactly, and all four are provided. Like Dusty said, it looks like a texture management issue.
06/11/2010 (9:39 am)
Quote: In fact looking at the code for 1.1A it wasn't using any states so it only tried to load the 4 images.
Exactly, and all four are provided. Like Dusty said, it looks like a texture management issue.
#9
08/21/2010 (9:55 am)
Logged as TQA-887. 
#10
I was able to set 75 buttons without a major performance hit.
Are you perhaps calling setbitmap("bitmapName.png") instead of setbitmap("bitmapName")?
If you are doing that, then double check that the following code is working:
In Function:
Line 648 on my version:
If it's finding the cached textureObj, then I'm not able to replicate your error and I'll need you to package your test case for me.
10/15/2011 (2:57 pm)
If you have state bitmaps turned on (which is default) a penalty due to a state file that it can't find is severe. Therefore, you need to know for sure that they are loading.I was able to set 75 buttons without a major performance hit.
Are you perhaps calling setbitmap("bitmapName.png") instead of setbitmap("bitmapName")?
If you are doing that, then double check that the following code is working:
In Function:
GFXTextureManager::createTexture( const Torque::Path &path, GFXTextureProfile *profile )
Line 648 on my version:
// Check the cache first... String pathNoExt = Torque::Path::Join( correctPath.getRoot(), ':', correctPath.getPath() ); pathNoExt = Torque::Path::Join( pathNoExt, '/', correctPath.getFileName() ); GFXTextureObject *retTexObj = _lookupTexture( pathNoExt, profile ); if( retTexObj ) return retTexObj;
If it's finding the cached textureObj, then I'm not able to replicate your error and I'll need you to package your test case for me.
Torque 3D Owner Ted Southard