+ Reply to Thread
Results 1 to 5 of 5

  Click here to go to the first Rift Team post in this thread.   Thread: Should a window that's just sitting there get CPU time?

  1. #1
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default Should a window that's just sitting there get CPU time?

    I'm messing around with a very preliminary version of LootSorter.

    The only event handler it has is for scrollbarchange. I am not touching the scrollbar. And the addon seems to be chewing up 2% CPU time. Just... sitting there. Displaying a window containing 20 lines of unchanging text and a scrollbar.

    It appears that this is all render time, according to Inspect.Addon.Cpu(). Is that reasonable? Should I be worrying about this, given that I'm only about 1/3 done populating the frame with prettiness?
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  2.   Click here to go to the next Rift Team post in this thread.   #2
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by the_real_seebs View Post
    I'm messing around with a very preliminary version of LootSorter.

    The only event handler it has is for scrollbarchange. I am not touching the scrollbar. And the addon seems to be chewing up 2% CPU time. Just... sitting there. Displaying a window containing 20 lines of unchanging text and a scrollbar.

    It appears that this is all render time, according to Inspect.Addon.Cpu(). Is that reasonable? Should I be worrying about this, given that I'm only about 1/3 done populating the frame with prettiness?
    Rendering isn't free. Yep, UI elements that are just sitting there will use CPU time. No way to avoid that - they gotta get rendered.

    The actual amount will be decreasing in the future - there's some optimizations I have in mind, including a fix for an efficiency problem with text - but it won't ever drop to zero.

  3. #3
    Shield of Telara Galdrin's Avatar
    Join Date
    Jul 2011
    Posts
    755

    Default

    In UI libraries, I usually see frames have a sort of "redraw needed" flag that, unless set by some relevant change (child redrawNeeded being set, text changing, scrollbar moved, etc etc), will allow a frame to be rendered from a cached texture and basically use no resources. Does Rift have such texture caching going on for its frames?

  4. #4
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    I noted my own addon using a more CPU than I'd have expected and I wondered since it isn't used during combat if I could unregister events when combat starts and re-register them when combat ends.

    In particular I'm registering Event.Buff.Add, Event.Buff.Remove, Event.Buff.Change as well as ones that will change a LOT in combat Event.Unit.Detail.Health & Event.Unit.Detail.Mana are two that come to mind as high occurrence events.

    At present I'm simply returning from the event routine if in combat but I'm thinking it would be more efficient to simply tell the API I'm not interested in events whilst in combat. I've not seen any examples of de-registering events so I'm not sure if its possible.

    Can anyone advise please?
    Last edited by Levva; 11-21-2011 at 03:22 PM.

  5.   This is the last Rift Team post in this thread.   #5
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Galdrin View Post
    In UI libraries, I usually see frames have a sort of "redraw needed" flag that, unless set by some relevant change (child redrawNeeded being set, text changing, scrollbar moved, etc etc), will allow a frame to be rendered from a cached texture and basically use no resources. Does Rift have such texture caching going on for its frames?
    You generally see this in non-3d-accelerated UIs. Marking elements for update went out of style with 3d acceleration - in the game industry that happened about a decade ago, in the desktop industry it's sort of happening right now.

    We'll probably have some speed improvements coming up, but it wouldn't surprise me if frame compositing ended up far slower than just rendering everything to screen.

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts