• 1
  • 3
  • 4
  • 5
  • 6
  • 7(current)
Aeon based skins slow ?
#91
jmarshall Wrote:Looks just fine to me as far as the output goes, though visible has an e Wink

If it's not visible, why is it being rendered (CGUIControl:Big GrinoRender) - or is this just the time taken in the visibility check? For groups, that time is in Render(), which should probably be split off.
I knew someone would bring up the visibl thing! Yeah I did that because it is the same number of characters as rendertime so it makes it easier to read in the XML.

The 2 numbers reported are for UpdateVisibility and Render, of course groups are sort of odd because the visibility numbers for their children contribute to the render time of the group. It probably could be done a little better but it definitely gives someone a pretty good idea where time is being spent.

It really kills performance when it is on (40fps down to 15fps), but it only turns on for 100 frames then turns off. It is rather unoptimal because it builds this large tree of objects and doesn't have a good way to search it other than brute force, but I really don't think it matters. When it is off it it just becomes a bool check. I've still gotta clean up my source tree a bit (did a lot of screwing around for fun) but I'll post the code tomorrow or so.
Reply
#92
OK, ignore me if this is a stupid question, but would it make any difference putting the <visible> tag at the very start of a control group?
Reply
#93
It makes no difference where the <visible> tag is placed in a particular control - we read them all and AND them together.

Obviously it's not good to put a visible condition on all the controls within a group instead of putting it on the group (though there are cases where that may possibly be necessary to get animations correct).

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#94
Actually, do I really need to output the amount of time spent doing UpdateVisibility? It takes 1% of overall time and I think it just makes the output more confusing. What do you think, Jonathan?
Reply
#95
It's not just 1% due to the number of groups involved, or are you accumulating the updatevisibility timings of the children into the time for the group?

Just having a general idea of the time to render each control would at least give an idea as to where to start looking though.

BTW: I think the reason the updatevisibility was in the same loop was so that control.isvisible() would work with controls further down the render order within the same group - i.e. they'd trigger at the same time. I'm not 100 on that though - will chat with Jezz_X and see if he has any ideas.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#96
The render+visibility time of child controls is counted as render time for a group because of that.

I could change it so that it reports the other way around for group controls, but that's really just me swapping render / visible because there's no way to separate the two at that level. I mean I guess I could do a lot of math to special case attempt to recalculate what the actual value is (subtract render time of children, add visiblity time of children, but starting at leaf children and working the way up) but as it stands right now the code is beautifully simple:
GUIPROFILER_RENDER_BEGIN(control);
Render();
GUIPROFILER_RENDER_END(control);

and the same thing with VISIBLE / UpdateVisibility. Probably should leave the visibil count in there the more I think about it.

EDIT: Because you're looking here, xbmc/utils/StreamDetails.cpp:420, VIDEOASPECT_EPSILON is no longer used after your aspect quantization change and can be removed.
Reply
#97
GUIControlProfiler patch posted as #6952
Reply
#98
Good if this could be resolved! I've tried many different skins, and all of them has been running very smooth. It's just Aeon that runs a bit slow, which is a pity 'cause it's the nicest skin! =)

If I enter Settings in Aeon I get lag directly, probably because of the images loaded at each different setting category. I guess this means that in my case it's the low amount of RAM on graphics card that is the problem? The same problem (gets a bit worse, but not very much) appears in Movies and everywhere else where images/pictures are loaded. The main menu runs smooth though =)
Reply
#99
CapnBry Wrote:GUIControlProfiler patch posted as #6952

Looking at your code, the needed modifications at the keymap file do not require a

guiprofilebegin

string, but a

guiprofile

one, in order to enable the gui profiler. Maybe the ticket text should be changed accordingly.
Anyway, great work!
Reply
Oh who changed that, Johnathan. /arms folded

Yeah it looks like it got committed as guiprofile instead of guiprofilebegin, way to make it confusing!
For troubleshooting and bug reporting please make sure you read this first.
Reply
It's spelled Jonathan. /arms folded :p

I left it as guiprofile as the output is called guiprofile.xml so I figured it was just as useful that way around. I also corrected the spelling of visible :p

I guess is should be added to the skinning manual as well.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7(current)

Logout Mark Read Team Forum Stats Members Help
Aeon based skins slow ?0