Thread Tools Display Modes
06-07-05, 07:23 AM   #1
diiverr
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 67
efficiency in adding graphical elements?

In regards to adding additional textures to the UI, I had until recently assumed that the bulk of burden on a given sytem would be related primarily to simply rendering the additional pixels.

Referencing information I learned here , and archived here , I think this may not be the case?

For those not familiar with my AddOn, DiivSkins, what it does is create textural backdrops for elements that wouldn't normally have them. Seperated MainBar elements, auxiliary action buttons, etc. The way this is currently done is to create a seperate new frame for each element I wish to "skin". In the case of an action bar made up of flexbuttons, this could include as many as 12 individual frames per bar, (one for each "slot"). I haven't counted, but concievably, DiivSkins could easily add over 100 additional frames to the "global environment". I'm not sure what sort of load this actually translates to, but I would have to assume it is, at the very least, not optimal.

I believe I could restructure my AddOn by use of the SetTexture function to utilize far far fewer frames. (As an off topic bonus, in the process, the configuration process for the AddOn could be made considerably more user friendly.)



This brings me to my question. Assuming I have the time and inclination to do a rewrite, would it be worth the effort, efficiency wise?



Processing wise, there would be likely a tenth (or even less) of the frame references to be handled by the global environment on any given application.



Currently, texture wise, any given DiivSkin bar is composed of one 128x64 pixel "base" with as many as 11 64x64 pixel "slots", or as many as 53,248 pixels. (do transparent pixels count?)

With the latter system, any given bar would be reduced to a single textCoord reference of ~8000 to ~30,000 pixels. So there is a significant difference there as well. (I may even be able to reduce this even farther if I get creative enough.)

The flip side to the texture deal is, that the first example only calls one example of the 128x64 and one example of the 64x64 texture to draw from. The SetTexture would have to (I assume) "park" a 512x512 texture somewhere in memory, although once there, it could be selectively referenced. (and again, if I can get creative enough, even this "base" texture may be able to be significantly reduced in overall size)



Sorry, I'm pretty foggy about just about everything I mentioned above, so I was just looking for any insight anyone might have, thanks.
  Reply With Quote
06-07-05, 08:30 AM   #2
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
I think texture size is mostly irrelevant. I notice that it's cached but not a permanent cache and independent of the garbage collection.

I don't follow the first part, but are you referencing already existing frames? Or does the xml file in your mod have 100s of frames?
  Reply With Quote
06-07-05, 09:28 AM   #3
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
texture load affects video memory and video performance mainly, but not enough to be a major concern. Granted having tons of textures stacked may cause issues on some systems, but overall with modern graphics, it should not be an issue unless the user is running with less than 64mb video ram.

The issue that you may run into however is script references, which utilizes system memory. That is where the 32mb AddOn memory setting comes into play. If you have TitanPanel or a similar addon that displays memory load you can see this actively, and tweak your addon to suit. For instance, my addons that are almost ready for release were utilizing somewhere around 12.5 mb average of the allotted AddOn cache, and after some tweaking I managed to get that down to 9mb. This is with ONLY my addons loaded, and nothing else (the optimal way of testing memory load in my opinion).

My suggestion is, use as few functions as you can to get by. if you have several functions in two or three addon "modules" that basically do the same thing, think about creating a single global common file, and have each module reference one function instead.

Any frame element that has a name uses a script reference, and as a result, a table that goes along with it (describing details about that element). The more you have that are named, the more load you put on system memory and AddOn memory.

So yeah, don't worry so much about video load as much as script memory and processing. If someone encounters slowdowns due to video / texture load from your addon, then they need to think about upgrading anyway, as I doubt wow runs superb for them...
  Reply With Quote
06-07-05, 10:23 AM   #4
diiverr
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 67
Originally Posted by Gello
I think texture size is mostly irrelevant. I notice that it's cached but not a permanent cache and independent of the garbage collection.

I don't follow the first part, but are you referencing already existing frames? Or does the xml file in your mod have 100s of frames?

The xml in my mod has 100's of frames. Well, probably not hundreds plural, but it does have over 100. Granted, they are likely rarely all visible during game play, but concievably its possible. Typically, the bulk, probably the majority, would be hidden during configuration.

With a re-write, I could reduce this dramatically. Basically one frame per element, with one texture reference, that could be changed (probably with a slider) by the user.


Originally Posted by Beladona
My suggestion is, use as few functions as you can to get by. if you have several functions in two or three addon "modules" that basically do the same thing, think about creating a single global common file, and have each module reference one function instead.

Any frame element that has a name uses a script reference, and as a result, a table that goes along with it (describing details about that element). The more you have that are named, the more load you put on system memory and AddOn memory.
If I read the quotes referenced by slouken correctly, come 1.6, all frames will be stored in memory? So even if I could get by without naming them (which I can't currently anyway), this would ultimately be moot anyway?

As per using fewer functions, this I think I can do with what I have in mind, at least for the bulk of the applications. Considering the functions are only called during set up for the most part, and not during actual game-play, I don't think this should be too much of an issue.


Thank you for the responses folks. I think I did have a pretty good handle on the texture size impact, although i didn't realize its significance was a small as I had anticipated. I did not realize the basic scripting of the AddOn could have that large of an impact however. I do have Titan, and his latest memory upgrade. With a "loaded" interface, including my AddOn, I didn't see anything I thought was too far out of the ordinary. That said, I will have to do some comparisons with out it, and without other AddOns, and then vs. what I can achieve using fewer frames.

It sounds like I can improve the impact DiivSkins has on system resources. I'll have to see what I can come up with.
  Reply With Quote
06-07-05, 10:54 AM   #5
diiverr
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 67
I'll try to illustrate what I'm talking about better.

currently, I have (paraphrased):

Code:
<Frame>
   <Size/>
   <Anchors/>
   <Layers/>
</Frame>
The above is repeated over and over in the xml, for each element presented. I used templates where i could for the size and layers, but that's the gist. In the case of a button tray, that's 12 frames, one for each slot, which are in turn manipulated entirely by the MoveAnything! AddOn. At the time, that was all I was capable of doing.

I'm still not saavy enough to understand all the internal workings of MoveAnything, but I would imagine this could potentially call it's functions into play as well, certainly during set-up, possibly even during game-play.

What I'm thinking of doing now is instead of having 12 of those frames, is have but 1 for any given "action bar" backdrop. Then, I would paint 1-12 slot "versions" of a backdrop that could be altered via a SetTexture. SquidMod does this for the default end-caps, via slash commands.

In Squidmod, after a variable is established using a slash command (I'm thinking of using sliders), the following is done in the lua:

Code:
function SquidMod_Update()

	if(SquidModSettings) then
			
		if(SquidModSettings.toggle == 0) then
			MainMenuBarLeftEndCap:Hide();
			MainMenuBarRightEndCap:Hide();
		elseif(SquidModSettings.toggle == 1) then
			MainMenuBarLeftEndCap:Show();
			MainMenuBarRightEndCap:Show();
			SquidModSettings.toggle = 2;
			SquidMod_Update();
		elseif(SquidModSettings.toggle == 2) then
			-- Thanx to Vjeux for SetTexture code
			MainMenuBarLeftEndCap:SetTexture("Interface\\AddOns\\SquidMod\\skin\\SquidModDefault.tga");
			MainMenuBarRightEndCap:SetTexture("Interface\\AddOns\\SquidMod\\skin\\SquidModDefault.tga");
		elseif(SquidModSettings.toggle == 3) then
			MainMenuBarLeftEndCap:SetTexture("Interface\\AddOns\\SquidMod\\skin\\BlizzDefault1.tga");
			MainMenuBarRightEndCap:SetTexture("Interface\\AddOns\\SquidMod\\skin\\BlizzDefault1.tga");
		elseif(SquidModSettings.toggle == 4) then
			MainMenuBarLeftEndCap:SetTexture("Interface\\AddOns\\SquidMod\\skin\\BlizzDefault2.tga");
			MainMenuBarRightEndCap:SetTexture("Interface\\AddOns\\SquidMod\\skin\\BlizzDefault2.tga");
		elseif(SquidModSettings.toggle == 5) then
etc.
end
The update is only called on a slash command with that addon, in my application, I am thinking I would call it on a slider <OnValueChanged>.

In essence, for every actionbar backdrop, I would ditch 11 frames for it's "slots" and just paint the appropriate texture called for by the slider and saved as a variable.

I could do the same thing for any image basically, even including a Show and a Hide function for variables. If I could sort locking and unlocking the various bits for movement, I imagine I could do away with the moveanything! dependency all together, leaving it optional if one wanted to resize elements.

Of course, I'm still fuzzy on saved variables, or more specifically, I think I would want a table? set up here for them, which im also fuzzy on, but that's another thread.
  Reply With Quote
06-07-05, 11:01 AM   #6
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
Hidden frames will take up as much memory as visible frames.

The primary reason for memory bloat is frequent creation of new strings/tables in OnUpdate handlers.

There's an excellent text in the wiki someplace about how memory is allocated. I wouldn't sweat creating too many static xml/lua elements. I'd be more careful with dynamically created structures like tables and frequently constructed strings.
  Reply With Quote
06-07-05, 11:28 AM   #7
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
agreed. If you absolutely MUST have data persistent throughtout the session, or even between sessions, then use static values. Otherwise, anything that can be created, destroyed, and created again (gargage collection) you cna put into local variables. Makes your mod more memory friendly that way.
  Reply With Quote

WoWInterface » Developer Discussions » General Authoring Discussion » efficiency in adding graphical elements?

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off