Keep GUIControls alive after window deinit #1283

Merged
merged 21 commits into from Sep 8, 2012

6 participants

@pieh
Team Kodi member

This is resurrection of #127 in much more complete state:

Window's controls are being deleted on window deinit. This results in loading xml, resolving includes, parsing resolved xml and creating controls everytime user activate window.

This will allow to keep controls objects in memory on window deinit. It also will store xml windows root node that could be used if load type is set to load_on_demand (old style - few windows are still like this) or if include condition have changed value.

Some numbers (tested on raspberry pi with slow sd card where it will have biggest impact I guess): compare alloc resources time for first and second window inits. (I didn't really gather data, just ran xbmc 3 times and given that results were similliar I called it done)

===== Results (numbers from Raspberry Pi) ====

  1. Home Window

     -- First window init will be same as usual --

    00:02:33 T:1096794832   DEBUG: ------ Window Init (Home.xml) ------
    00:02:33 T:1096794832    INFO: Loading skin file: Home.xml, load type: on demand and keep in memory after window deinit
    00:02:33 T:1096794832   DEBUG: Load Home.xml: 665.98ms
    00:02:34 T:1096794832   DEBUG: Alloc resources: 723.72ms  (666.55 ms skin load)

     -- Second window init --

    00:03:24 T:1096794832   DEBUG: ------ Window Init (Home.xml) ------
    00:03:24 T:1096794832   DEBUG: Window Home.xml was already loaded
    00:03:24 T:1096794832   DEBUG: Alloc resources: 22.07m

  2. Video Nav

    00:03:18 T:1096794832   DEBUG: ------ Window Init (MyVideoNav.xml) ------
    00:03:18 T:1096794832    INFO: Loading skin file: MyVideoNav.xml, load type: on demand and keep in memory after window deinit
    00:03:19 T:1096794832   DEBUG: Load MyVideoNav.xml: 776.83ms
    00:03:19 T:1096794832   DEBUG: Alloc resources: 827.03ms  (777.33 ms skin load)

    00:03:30 T:1096794832   DEBUG: ------ Window Init (MyVideoNav.xml) ------
    00:03:30 T:1096794832   DEBUG: Window MyVideoNav.xml was already loaded
    00:03:30 T:1096794832   DEBUG: Alloc resources: 27.48m

On android (skin.retouched) Home.xml was loaded 1st time: 126ms and 2nd time: 5ms (that's total alloc resources time). On my desktop with ssd - home.xml = 1st time: 42ms, 2nd time: 4ms. So it's not that spectacular everywhere. Note: alloc resources times don't include time spent in OnWindowInit (f.e. video nav window fetch directory there)!

Here's list of windows that weren't yet adjusted/tested if they will work "as-is":

Still on to-do list but not really high priority:
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: screencalibration (file: SettingsScreenCalibration.xml, ID: 10011)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: filestackingdialog (file: DialogFileStacking.xml, ID: 12008)

Didn't have any karaoke samples so at least for now I leave them as they are with old style xml loading every init. Do they still work at all?
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: karaokeselector (file: DialogKaraokeSongSelector.xml, ID: 10143)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: karaokelargeselector (file: DialogKaraokeSongSelectorLarge.xml, ID: 10144)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: karaoke (file: MusicKaraokeLyrics.xml, ID: 12009)

For no-xml windows load type doesn't matter so they can stay as they are.
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: teletext (file: no xml file, ID: 10600)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: unkown window (file: no xml file, ID: 97) <= Dim Screensaver Window
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: unkown window (file: no xml file, ID: 98) <= Debug Overlay Window
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: screensaver (file: no xml file, ID: 12900)

CGUIDialogSubMenu class used only as base for "submenu" type custom windows (which wasn't used by any of few skins I have: confluence, aeon-nox, xeebo). No DialogSubMenu.xml in confluence. Nuke that window?
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: submenu (file: DialogSubMenu.xml, ID: 10105)

Used only after playing with GUISetting that aren't shown in GUI. No DialogAccessPoints.xml in confluence. Nuke that window?
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: accesspoints (file: DialogAccessPoints.xml, ID: 10141)

Loaded and shown once - no sense in keeping it in memory.
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: startup (file: Startup.xml, ID: 12999)

And finally - my branch currently contains 2(3) last temporary commits (they will be removed later) to
1. help me notice what windows weren't adjusted yet (it generated window list above)
2. enable/disable feature on runtime (in gui settings) to check what impact it have
(3). add window loadtype to log on window load (depends on how verbose we want to be)

@jmarshallnz
Team Kodi member

Ok, main thing is I think we need to clearly identify where we need overriding in the subclasses. Seems to me we have:

  1. After XML load and before control parsing (for python label parsing).
  2. After control parsing (filling default content that anims and control state might need). Should run once we have controls either from in memory or from a load.
  3. After window is up, anims are all setup and we're ready to go (filling in content). Should run every init.

... window cycle ...

  1. After window close animation and before controls are cleared (reset controls to default state).
  2. After controls are cleared and before unload (not sure if needed)
  3. After XML unload.

Not sure about 2/3 vs 5/6

@pieh
Team Kodi member

I don't understand what You mean with "python label parsing" (or I'm propably totally unaware that we do something like that?).

I don't think we should change where/when we call existing callbacks (this would propably cause serious regressions which I already faced once and it took me quite a long time to finalize it). But adding new callbacks would be ok I think (and wouldn't hurt).

@jmarshallnz
Team Kodi member

IIRC winxml windows parse for existing Localise stuff and bumps the string IDs up as needed?

@pieh
Team Kodi member

Right, found it - CGUIPythonWindowXML is overriding CGUIWindow::LoadXML. It manipulates directly on xml string (before parsing) to replace SCRIPT### to proper ID - do we want callback that will pass xml as string so it can be manipulated? Doesn't seem nice to me.

@pieh
Team Kodi member

Added bunch of changes (additional commits will be squashed later). Wanted to keep comment history so we can track what is already taken care of.

@jmarshallnz
Team Kodi member

Looks like we can do cases 2 and 3 above via OnInitWindow, as that runs every time, right? So we could do:

DerivedClass::OnInitWindow()
{
// do whatever needs doing in 2

BaseClass::OnInitWindow() // sets up animations etc.

// do whatever needs doing in 3
}

So I don't think we need a new callback there.

@jmarshallnz
Team Kodi member

Changes look good

@pieh pieh was assigned Sep 5, 2012
pieh added some commits Feb 15, 2012
@pieh pieh allow include resolver to store checked include conditions and their …
…values into map<conditionID:int, value:bool>

store conditions and values used to resolve includes in CGUIWindow
added CGUIInfoManager::ConditionsChangedValues method
fb6a3f0
@pieh pieh change bool m_loadOnDemand to LOAD_TYPE m_loadType 5671a6a
@pieh pieh allow not to free memory (destroy controls objects) when exiting window
added additional checks in AllocResources - we have to load .xml file if:
 - load type is set to LOAD_EVERY_TIME (all windows use it by default)
 - window is loaded and any of include condition have changed value
 - window isn't loaded

we have to unload window before loading if window wasn't unloaded before and include conditions have change value(s)
afffab0
@pieh pieh store and reuse window xml root node
this allows to avoid reading and parsing xml file in windows we already used before and are loaded on demand or their include conditions have changed values
996bd17
@pieh pieh regression fix: override SetInitialVisibility() in CGUIBaseContainer …
…to force restoring static items before restoring control states ( in CGUIWindow::OnInitWindow, SetInitialVisibility() is called before RestoreControlStates() )

not need to call UpdateStaticItems() if we are loading static items from .xml as we do it before SetInitialVisibility is called and it will be called there
f2e9d06
@pieh pieh adjust GUIDialogContextMenu: cleaning up initialization/deinitializat…
…ion of dialog

- we need additional members to remember window coordinates (these are fetched while loading window .xml file and later are changed when setting position of ContextMenu) and size of background image
- we don't need to call SetInitialVisibility - it's alreadu done in CGUIWindow::OnWindowInit
- we need to manually remove choice buttons in OnDeinitWindow
- we need to store size of background image to properly set its size it in consequent showings
e30dbc2
@pieh pieh keep these windows in memory, they're ready as-is 4ce5d78
@pieh pieh adjust GUIDialogBoxBase: store heading,lines,choices and set them whe…
…n initing window and if dialog is already active
158c99b
@pieh pieh adjust GUISlideShow: move stoping background loader to window deinit 53eabbf
@pieh pieh adjust GUIDialogMediaSource: clear list with paths on deinit bb3a2bc
@pieh pieh adjust GUIDialogSelect: don't reset GUIViewControl when leaving windo…
…w, clear it

reset it when we unload window
b5843d8
@pieh pieh adjust GUIDialogNetworkSetup: change control types only when we load …
…window, fill/clear protocol spinner when we init/deinit window
d260bfb
@pieh pieh adjust GUIDialogPeripheralManager: we would run OnInitWindow twice du…
…e to not consuming GUI_MSG_WINDOW_INIT message

also move init actions to OnInitWindow callback
4e00b80
@pieh pieh adjust GUIDialogVideoScan: hide progress controls if not used 83a3f44
@pieh pieh adjust GUIDialogSlider: nullify callbacks on window deinit 5eadd51
@pieh pieh adjust GUIWindowFullscreen: don't toggle DynamicResourceAlloc, shuffl…
…e deinit order a little and let generic window code to handle control unloading/freeing
32fdcd9
@pieh pieh adjust GUIDialogTextViewer: reset textarea and heading controls after…
… deinit
aa037df
@pieh pieh adjust GUIDialogSmartPlaylistEditor: move playlist type specific conf…
…iguration to OnInitWindow
00bd5fb
@pieh pieh adjust GUIDialogSmartPlaylistRule: clear rule spinner before filling …
…it, clear rule and operand spinner on deinit and try to change value button to edit control just once on window load
5649658
@pieh pieh adjust GUIWindowSystemInfo: clear labels on window deinit d11b741
@pieh pieh log: add window loadType to debug log on window load 7614940
@pieh pieh merged commit 2cc5bc9 into xbmc:master Sep 8, 2012
@Voyager1
Team Kodi member

I'm noticing problems with stale information still being displayed in some of the labels on the Video Info dialog (CGUIDialogVideoInfo), e.g. the file path, the media labels (1080, xvid, bluray etc.) and others. When some label is "empty" the next time, it does not replace what was there the last time.

I believe that it has to do with this new feature. Just like what was done with other windows/dialogs part of this change, we probably need to clear the labels in the DEINIT event?

@pieh
Team Kodi member

right, I must have missed it, will fix it

@Voyager1
Team Kodi member

just confirming that as a temp fix, I commented out m_loadType = KEEP_IN_MEMORY; in the CGUIDialogVideoInfo constructor.

@Voyager1
Team Kodi member

Same problem with CGUIDialogMusicInfo. Just get the album info for one, then for the next. Doesn't update.

@pieh
Team Kodi member

hmm, this is weird - what skin are you using?

@Voyager1
Team Kodi member

Confluence, the standard!

@Voyager1
Team Kodi member

just tested with commenting out the keep in memory, fixes the issue again for the album info (CGUIDialogMusicInfo)

@Voyager1
Team Kodi member

you have to look closely, it's the artist, genre, rating, year and the artwork that remain the same as the first one you opened...

@pieh
Team Kodi member

right, it's something with rendering - if you'll hover mouse on it it will refresh

@Voyager1
Team Kodi member

i saw that too. (although I used the keyboard arrows). So how to fix?

@elupus
Team Kodi member
@pieh
Team Kodi member

this is problem with controls in containers - they refresh only when layout is marked invalid, will fix that
EDIT: well that's not the problem - will fix layout not being invalidated

@pieh
Team Kodi member

fixed in 8b796ee

@Voyager1
Team Kodi member

just tried it. it's not entirely fixed: the media flags still don't update correctly. Eg. the first one I view is bluray, the next one not, but the flag is still there.

EDIT: same with the music albums. Try an album with cover art, then another without. The first album art is still displayed...

@pieh
Team Kodi member

@Voyager-xbmc
here's my proposed fix for that pieh@affcec9 - it fixes given issue, just not sure it won't cause another. Won't push it yet because i'm going off for the weekend and don't won't to introduce any unknown bug when I'm bit available.

@Voyager1
Team Kodi member

@pieh - thanks for the great work. I was close to the same solution (only the 2nd if though) but I think this is it. I'll play with it - happy to report experiences after the weekend :-)

@jmarshallnz
Team Kodi member
@Voyager1
Team Kodi member

@jmarshallnz - the issue is that pieh's PR altered the way windows get loaded. Previously they were loaded every time, now they stay in memory and get reused, thereby speeding up the GUI. This means that controls don't get reinitialised via constructor. In between inits an image on a window should be able to change, e.g. the album art, the media flag images... The problem was that if we went from an "old" image with an actual texture in it (e.g the 720.png flag) to a "new" image path that was empty (e.g. no flag set), somehow it didn't change the texture. By debugging I found that the m_currentTexture would indeed be empty, but the m_texture.m_info filename was still the old one (e.g. 720.png). It turned out m_texture.SetFileName wasn't called, nor did we mark the dirtyregion.

Edit:
don't know if this is useful, but anyway, I first tried to resolve it by calling m_texture.setFileName in CGUIImage::FreeTextures, to resolve the issue of the old filename still being there, but that didn't help. You also need to mark the image dirty, but that caused too many issues so I abandoned.

@pieh
Team Kodi member
@jmarshallnz
Team Kodi member
@Voyager1
Team Kodi member

tried this, and it works. Just don't empty the m_currentTexture anymore, so the comparison with strFileName in ::SetFileName works properly. I checked and m_currentTexture isn't much used anywhere else. I also tried messing with clearing out the texture info (m_info.filename) in the free texture method, but that creates a lot of issues with the gui...

void CGUIImage::FreeTextures(bool immediately /* = false */)
{
  m_texture.FreeResources(immediately);
  for (unsigned int i = 0; i < m_fadingTextures.size(); i++)
    delete m_fadingTextures[i];
  m_fadingTextures.clear();
  //m_currentTexture.Empty(); <-- remove this!
} 
@jmarshallnz
Team Kodi member
@Voyager1
Team Kodi member

the problem is more than just keeping them in sync.
Here's what happens if you call m_texture.SetFilename in CGUIImage::FreeTextures:

http://imageshack.us/a/img703/5720/screenshot001yo.png

@Voyager1
Team Kodi member

and when you move the m_texture.SetFileName(m_currentTexture); as the first line to CGUIImage::AllocResources, results are even worse. Lots of textures missing.

http://imageshack.us/a/img152/6313/screenshot000u.png

Somehow, I think that my proposal to NOT clear m_currentTexture is the least intrusive. This member variable is just used to carry the latest texture filename used, nothing else. Not clearing it means you can appropriately track a change from a non-empty to an empty picture...

@pieh
Team Kodi member

@Voyager-xbmc
this line ( abbacb5 ) was added as part of the fix for http://trac.xbmc.org/ticket/9926 . Not sure if it's ok to remove it completely, so here's my next attempt: pieh@13c843b

this won't make textures dissapear - problem with disappearing textures is that if texture path is constant (as in no InfoLabels are used, so all confluence textures) we will only update texture once - when we create image control. This won't break it because constant texture path doesn't use m_currentFile (leaving it empty) so when I try to set file name in ::FreeTextures it won't have any effect (as new and old path are both empty)

it still isn't as nice as I would like it (mostly part that it won't break constant textures "only by accident"), but at least better than previous "fix"

@jmarshallnz
Team Kodi member

Isn't that identical to calling m_texture.SetFilename("") after resetting m_current texture ?

@Voyager1
Team Kodi member

@jmarshallnz : I would say it's almost identical, with the exception of two things: checking the value already in m_currentTexture (don't do anything if already empty) and the dirty region handling. With pieh's solution working fine, I have adapted it as follows. Note that without the if (!m_currentTexture.Equals("")) you get again a lot of empty/missing images as in my screenshots above.

void CGUIImage::FreeTextures(bool immediately /* = false */)
{
  m_texture.FreeResources(immediately);
  for (unsigned int i = 0; i < m_fadingTextures.size(); i++)
    delete m_fadingTextures[i];
  m_fadingTextures.clear();
  if (!m_currentTexture.Equals(""))
  {
    m_currentTexture = "";
    if (m_texture.SetFileName(m_currentTexture))
      MarkDirtyRegion();
  }
}
@jmarshallnz
Team Kodi member
@Voyager1
Team Kodi member

You're right. Reduced it to the following, and still works ok:

void CGUIImage::FreeTextures(bool immediately /* = false */)
{
  m_texture.FreeResources(immediately);
  for (unsigned int i = 0; i < m_fadingTextures.size(); i++)
    delete m_fadingTextures[i];
  m_fadingTextures.clear();
  if (!m_currentTexture.IsEmpty())
  {
    m_currentTexture.Empty();
    m_texture.SetFileName(m_currentTexture);
  }
}

So it seems that the if guard is what is making the difference. Probably FreeTextures is called when m_currentTexture is already empty but m_texture is not, in which case without the if guard we would empty the m_texture's filename, thus causing the missing images from my screenshots above.

@Voyager1
Team Kodi member

Additional info: So it seems to work fine with the code I posted above. However, there are now still cases where m_currentTexture is empty while m_texture's filename is not. Apparently m_texture's filename is set in a number of places in CGUIImage, without syncing m_currentTexture, e.g. the contstructors, CGUIImage::Process and CGUIImage::SetInfo. I tried to make sure we sync it in all those places, but then the problem I described with the screenshots reappears. Similarly, I removed m_currentTexture everywhere and replaced it with m_texture.GetFileName() - same issue. I don't know the code enough, but it seems that those two are not really meant to be in sync at all times.

@pieh
Team Kodi member

Additional info: So it seems to work fine with the code I posted above. However, there are now still cases where m_currentTexture is empty while m_texture's filename is not. Apparently m_texture's filename is set in a number of places in CGUIImage, without syncing m_currentTexture, e.g. the contstructors, CGUIImage::Process and CGUIImage::SetInfo. I tried to make sure we sync it in all those places, but then the problem I described with the screenshots reappears. Similarly, I removed m_currentTexture everywhere and replaced it with m_texture.GetFileName() - same issue. I don't know the code enough, but it seems that those two are not really meant to be in sync at all times.

There are 2 cases: we use constant texture path: f.e. "floor.png" or we use dynamic texture path: f.e. "$INFO[ListItem.Icon]". First one will just set texture's filename in CGUI::SetInfo without using m_currentTexture at all (so it will stay empty) - in this case we can't simply reset texture's filename as we won't update texture next time we load window (that's why there are missing textures as texture has empty path). Second one will be evaluated each frame and compared to m_currentTexture and update both m_currentTexture and texture object if it changed - so as long as we keep m_texture and m_currentTexture in sync it will be good.

So IMO good solution would be to both clear m_currentTexture and m_texture and set texture path in method that is called when window is inited. There's obviously catch as this method would be ::AllocResources but CGUIImage has DynamicResourceAlloc flag set which means AllocResoures won't be called on window init and image control itself is in charge of allocating resources. I will try to get around this and see what I can come up with.

@pieh
Team Kodi member

here's another take on it: pieh@a5b3b36

@Voyager1
Team Kodi member

tried it, and looks good. I don't know if there is a real reason to keep m_currentTexture empty for the constant textures. In any case I tried your solution, it works. I have also tried modifying it to also sync m_currentTexture in ::AllocResources and that works too.

    if (m_info.IsConstant()) 
    {
      m_texture.SetFileName(m_info.GetLabel(0)); 
      m_currentTexture = m_texture.GetFileName();
    }
@jmarshallnz
Team Kodi member
@Voyager1
Team Kodi member

@jmarshallnz - just to make sure, you mean it like this?

void CGUIImage::FreeTextures(bool immediately /* = false */)
{
  m_texture.FreeResources(immediately);
  for (unsigned int i = 0; i < m_fadingTextures.size(); i++)
    delete m_fadingTextures[i];
  m_fadingTextures.clear();
  if (!m_info.IsConstant()) // constant textures never change 
  {
    m_currentTexture.Empty();
    m_texture.SetFileName(m_currentTexture);
  }
}
@jmarshallnz
Team Kodi member
@Voyager1
Team Kodi member

@jmarshallnz - got it. This works too. Thanks!!

void CGUIImage::FreeTextures(bool immediately /* = false */)
{
  m_texture.FreeResources(immediately);
  for (unsigned int i = 0; i < m_fadingTextures.size(); i++)
    delete m_fadingTextures[i];
  m_fadingTextures.clear();
  m_currentTexture.Empty();
  if (!m_info.IsConstant()) // constant textures never change 
    m_texture.SetFileName("");
}
@pieh
Team Kodi member

@jmarshallnz
here's pack of fixes for regressions I've introduced (first 3 commits), including one we were discussing + additional "improvment" for multiimage to avoid loading directory 2 times on alloc: https://github.com/pieh/xbmc/compare/empty_image_fix

push them or they need more work?

@jmarshallnz
Team Kodi member
@dersphere
Team Kodi member

This causes issue #13351 (http://trac.xbmc.org/ticket/13351).
In short: "Choose a Scraper" and "Current Scraper" are empty on second enter of CGUIDialogContentSettings:
On first init m_scrapers are being filled, on deinit they are cleared and on second open they are not beeing re-filled.

I would fix that with an PR but I don't know what is the desired way ;-)

@t-nelson
@LongChair LongChair added a commit to plexinc/plex-home-theater-public that referenced this pull request Aug 1, 2014
@LongChair LongChair Fix Cannot jump to home from Extras strip #1283
When you have a scrolling list, Application will try first to send the message to the window rather than processing it.
in the case of 'h' key, and on preplay window, the BUILTIN message will come down to preplay window and be handled by a controlgroup that will put it in an onclick message forwarded to the controls. this is pretty much insane.

So we just say that we dont wanna handle builtins, then Application will handle them properly.
427b5a8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment