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.