Keep GUIControls alive after window deinit #1283

Merged
merged 21 commits into from Sep 8, 2012

Conversation

Projects
None yet
6 participants
@pieh
Member

pieh commented Aug 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Aug 13, 2012

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

Member

jmarshallnz commented Aug 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Aug 13, 2012

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).

Member

pieh commented Aug 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Aug 13, 2012

Member

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

Member

jmarshallnz commented Aug 13, 2012

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

@pieh

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Aug 13, 2012

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.

Member

pieh commented Aug 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Aug 14, 2012

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.

Member

pieh commented Aug 14, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Aug 14, 2012

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.

Member

jmarshallnz commented Aug 14, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Aug 14, 2012

Member

Changes look good

Member

jmarshallnz commented Aug 14, 2012

Changes look good

@ghost ghost assigned pieh Sep 5, 2012

pieh added some commits Feb 15, 2012

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
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)
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
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
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
adjust GUIDialogBoxBase: store heading,lines,choices and set them whe…
…n initing window and if dialog is already active
adjust GUIDialogNetworkSetup: change control types only when we load …
…window, fill/clear protocol spinner when we init/deinit window
adjust GUIDialogPeripheralManager: we would run OnInitWindow twice du…
…e to not consuming GUI_MSG_WINDOW_INIT message

also move init actions to OnInitWindow callback
adjust GUIWindowFullscreen: don't toggle DynamicResourceAlloc, shuffl…
…e deinit order a little and let generic window code to handle control unloading/freeing
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

pieh added a commit that referenced this pull request Sep 8, 2012

Merge pull request #1283 from pieh/window_load_on_demand
Keep GUIControls alive after window deinit

@pieh pieh merged commit 2cc5bc9 into xbmc:master Sep 8, 2012

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

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?

Member

Voyager1 commented Sep 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 13, 2012

Member

right, I must have missed it, will fix it

Member

pieh commented Sep 13, 2012

right, I must have missed it, will fix it

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

Member

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

Member

Voyager1 commented Sep 13, 2012

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

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

Member

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

Member

Voyager1 commented Sep 13, 2012

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

@pieh

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 13, 2012

Member

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

Member

pieh commented Sep 13, 2012

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

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

Member

Confluence, the standard!

Member

Voyager1 commented Sep 13, 2012

Confluence, the standard!

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

Member

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

Member

Voyager1 commented Sep 13, 2012

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

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

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...

Member

Voyager1 commented Sep 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 13, 2012

Member

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

Member

pieh commented Sep 13, 2012

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

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

Member

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

Member

Voyager1 commented Sep 13, 2012

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

@elupus

This comment has been minimized.

Show comment
Hide comment
@elupus

elupus Sep 13, 2012

Member

Dirty rendering problem. The control is not marked as dirty for som reason.

Member

elupus commented Sep 13, 2012

Dirty rendering problem. The control is not marked as dirty for som reason.

@pieh

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 13, 2012

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

Member

pieh commented Sep 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 13, 2012

Member

fixed in 8b796ee

Member

pieh commented Sep 13, 2012

fixed in 8b796ee

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

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...

Member

Voyager1 commented Sep 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 13, 2012

Member

@voyager-xbmc
here's my proposed fix for that pieh/xbmc@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.

Member

pieh commented Sep 13, 2012

@voyager-xbmc
here's my proposed fix for that pieh/xbmc@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

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 13, 2012

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 :-)

Member

Voyager1 commented Sep 13, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 14, 2012

Member

This seems to suggest some other problem is present to me. If the texture
is not allocated, we shouldn't be fading one out. Similarly we shouldn't
have a current image set? Don't controls become deallocated when the window
disappears? Perhaps m_currentTexture needs to be set empty at that point?

With that said, at least the second bit shouldn't be a problem as
CGUITexture takes care of not doing anything if the path is the same.

Another thing I'm not sure about is why the same image path would be used
for two different images anyway? What's the actual issue here?

On Thursday, September 13, 2012, Voyager-xbmc wrote:

@pieh https://github.com/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 :-)


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8543793.

Member

jmarshallnz commented Sep 14, 2012

This seems to suggest some other problem is present to me. If the texture
is not allocated, we shouldn't be fading one out. Similarly we shouldn't
have a current image set? Don't controls become deallocated when the window
disappears? Perhaps m_currentTexture needs to be set empty at that point?

With that said, at least the second bit shouldn't be a problem as
CGUITexture takes care of not doing anything if the path is the same.

Another thing I'm not sure about is why the same image path would be used
for two different images anyway? What's the actual issue here?

On Thursday, September 13, 2012, Voyager-xbmc wrote:

@pieh https://github.com/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 :-)


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8543793.

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 14, 2012

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.

Member

Voyager1 commented Sep 14, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 14, 2012

Member

@jmarshallnz
Problem is we clear m_currentTexture string in CGUIImage::FreeTexture
(which is called by ::FreeResources) but we dont keep m_texture in sync. So
if infolabel switch value to empty while control is after ::FreeResources
but before ::AllocResources we won't update texture and thus will use stale
texture info (as btoh m_currentTexture and and new value of infolabel is
empty, so they're equal, so textureinfo won't be updated).

I will check it after weekend and do proper PR for it.
On Sep 14, 2012 10:29 AM, "jmarshallnz" notifications@github.com wrote:

This seems to suggest some other problem is present to me. If the texture
is not allocated, we shouldn't be fading one out. Similarly we shouldn't
have a current image set? Don't controls become deallocated when the
window
disappears? Perhaps m_currentTexture needs to be set empty at that point?

With that said, at least the second bit shouldn't be a problem as
CGUITexture takes care of not doing anything if the path is the same.

Another thing I'm not sure about is why the same image path would be used
for two different images anyway? What's the actual issue here?

On Thursday, September 13, 2012, Voyager-xbmc wrote:

@pieh https://github.com/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 :-)


Reply to this email directly or view it on GitHub<
https://github.com/xbmc/xbmc/pull/1283#issuecomment-8543793>.


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8554736.

Member

pieh commented Sep 14, 2012

@jmarshallnz
Problem is we clear m_currentTexture string in CGUIImage::FreeTexture
(which is called by ::FreeResources) but we dont keep m_texture in sync. So
if infolabel switch value to empty while control is after ::FreeResources
but before ::AllocResources we won't update texture and thus will use stale
texture info (as btoh m_currentTexture and and new value of infolabel is
empty, so they're equal, so textureinfo won't be updated).

I will check it after weekend and do proper PR for it.
On Sep 14, 2012 10:29 AM, "jmarshallnz" notifications@github.com wrote:

This seems to suggest some other problem is present to me. If the texture
is not allocated, we shouldn't be fading one out. Similarly we shouldn't
have a current image set? Don't controls become deallocated when the
window
disappears? Perhaps m_currentTexture needs to be set empty at that point?

With that said, at least the second bit shouldn't be a problem as
CGUITexture takes care of not doing anything if the path is the same.

Another thing I'm not sure about is why the same image path would be used
for two different images anyway? What's the actual issue here?

On Thursday, September 13, 2012, Voyager-xbmc wrote:

@pieh https://github.com/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 :-)


Reply to this email directly or view it on GitHub<
https://github.com/xbmc/xbmc/pull/1283#issuecomment-8543793>.


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8554736.

@jmarshallnz

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 14, 2012

Member

Perhaps we should clear out the texture info in free texture then? This
wasn't an issue before as control was killed.

On Friday, September 14, 2012, Michal Piechowiak wrote:

@jmarshallnz
Problem is we clear m_currentTexture string in CGUIImage::FreeTexture
(which is called by ::FreeResources) but we dont keep m_texture in sync.
So
if infolabel switch value to empty while control is after ::FreeResources
but before ::AllocResources we won't update texture and thus will use
stale
texture info (as btoh m_currentTexture and and new value of infolabel is
empty, so they're equal, so textureinfo won't be updated).

I will check it after weekend and do proper PR for it.
On Sep 14, 2012 10:29 AM, "jmarshallnz" <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>>
wrote:

This seems to suggest some other problem is present to me. If the
texture
is not allocated, we shouldn't be fading one out. Similarly we shouldn't
have a current image set? Don't controls become deallocated when the
window
disappears? Perhaps m_currentTexture needs to be set empty at that
point?

With that said, at least the second bit shouldn't be a problem as
CGUITexture takes care of not doing anything if the path is the same.

Another thing I'm not sure about is why the same image path would be
used
for two different images anyway? What's the actual issue here?

On Thursday, September 13, 2012, Voyager-xbmc wrote:

@pieh https://github.com/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 :-)


Reply to this email directly or view it on GitHub<
https://github.com/xbmc/xbmc/pull/1283#issuecomment-8543793>.


Reply to this email directly or view it on GitHub<
https://github.com/xbmc/xbmc/pull/1283#issuecomment-8554736>.


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8562158.

Member

jmarshallnz commented Sep 14, 2012

Perhaps we should clear out the texture info in free texture then? This
wasn't an issue before as control was killed.

On Friday, September 14, 2012, Michal Piechowiak wrote:

@jmarshallnz
Problem is we clear m_currentTexture string in CGUIImage::FreeTexture
(which is called by ::FreeResources) but we dont keep m_texture in sync.
So
if infolabel switch value to empty while control is after ::FreeResources
but before ::AllocResources we won't update texture and thus will use
stale
texture info (as btoh m_currentTexture and and new value of infolabel is
empty, so they're equal, so textureinfo won't be updated).

I will check it after weekend and do proper PR for it.
On Sep 14, 2012 10:29 AM, "jmarshallnz" <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>>
wrote:

This seems to suggest some other problem is present to me. If the
texture
is not allocated, we shouldn't be fading one out. Similarly we shouldn't
have a current image set? Don't controls become deallocated when the
window
disappears? Perhaps m_currentTexture needs to be set empty at that
point?

With that said, at least the second bit shouldn't be a problem as
CGUITexture takes care of not doing anything if the path is the same.

Another thing I'm not sure about is why the same image path would be
used
for two different images anyway? What's the actual issue here?

On Thursday, September 13, 2012, Voyager-xbmc wrote:

@pieh https://github.com/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 :-)


Reply to this email directly or view it on GitHub<
https://github.com/xbmc/xbmc/pull/1283#issuecomment-8543793>.


Reply to this email directly or view it on GitHub<
https://github.com/xbmc/xbmc/pull/1283#issuecomment-8554736>.


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8562158.

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 14, 2012

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!
} 
Member

Voyager1 commented Sep 14, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 15, 2012

Member

I'd think that calling m_texture.SetFileName would do the trick, and seems
like the nicer fix than keeping stale information around. The problem is
not m_currentTexture, but rather that m_texture isn't in sync with it. An
alternate fix would be always calling m_texture.SetFileName in the alloc
methods?

On Friday, September 14, 2012, Voyager-xbmc wrote:

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();
}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8575689.

Member

jmarshallnz commented Sep 15, 2012

I'd think that calling m_texture.SetFileName would do the trick, and seems
like the nicer fix than keeping stale information around. The problem is
not m_currentTexture, but rather that m_texture isn't in sync with it. An
alternate fix would be always calling m_texture.SetFileName in the alloc
methods?

On Friday, September 14, 2012, Voyager-xbmc wrote:

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();
}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8575689.

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 15, 2012

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

Member

Voyager1 commented Sep 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 15, 2012

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...

Member

Voyager1 commented Sep 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 17, 2012

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/xbmc@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"

Member

pieh commented Sep 17, 2012

@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/xbmc@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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 18, 2012

Member

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

Member

jmarshallnz commented Sep 18, 2012

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

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 18, 2012

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();
  }
}
Member

Voyager1 commented Sep 18, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 18, 2012

Member

You needn't mark the region dirty.
On Sep 18, 2012 7:50 AM, "Voyager-xbmc" notifications@github.com wrote:

@jmarshallnz https://github.com/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();
}}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8641974.

Member

jmarshallnz commented Sep 18, 2012

You needn't mark the region dirty.
On Sep 18, 2012 7:50 AM, "Voyager-xbmc" notifications@github.com wrote:

@jmarshallnz https://github.com/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();
}}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8641974.

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 18, 2012

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.

Member

Voyager1 commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 18, 2012

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.

Member

Voyager1 commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 18, 2012

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.

Member

pieh commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 18, 2012

Member

here's another take on it: pieh/xbmc@a5b3b36

Member

pieh commented Sep 18, 2012

here's another take on it: pieh/xbmc@a5b3b36

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 18, 2012

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();
    }
Member

Voyager1 commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 18, 2012

Member

if (!m_info.IsConstant()) // constant textures never change
m_texture.SetTexture("");

In the same place we reset m_currentTexture.
On Sep 18, 2012 7:05 PM, "Voyager-xbmc" notifications@github.com wrote:

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();
}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8662154.

Member

jmarshallnz commented Sep 18, 2012

if (!m_info.IsConstant()) // constant textures never change
m_texture.SetTexture("");

In the same place we reset m_currentTexture.
On Sep 18, 2012 7:05 PM, "Voyager-xbmc" notifications@github.com wrote:

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();
}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8662154.

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 19, 2012

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);
  }
}
Member

Voyager1 commented Sep 19, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 19, 2012

Member

Put the m_currentTexture.Empty() outside the if I think?

On Wed, Sep 19, 2012 at 5:50 PM, Voyager-xbmc notifications@github.comwrote:

@jmarshallnz https://github.com/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);
}}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8679988.

Member

jmarshallnz commented Sep 19, 2012

Put the m_currentTexture.Empty() outside the if I think?

On Wed, Sep 19, 2012 at 5:50 PM, Voyager-xbmc notifications@github.comwrote:

@jmarshallnz https://github.com/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);
}}


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8679988.

@Voyager1

This comment has been minimized.

Show comment
Hide comment
@Voyager1

Voyager1 Sep 19, 2012

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("");
}
Member

Voyager1 commented Sep 19, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@pieh

pieh Sep 19, 2012

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?

Member

pieh commented Sep 19, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Sep 19, 2012

Member

The first 3 look fine. Not sure the 4th is needed - see my comment there.

On Thu, Sep 20, 2012 at 8:11 AM, Michal Piechowiak <notifications@github.com

wrote:

@jmarshallnz https://github.com/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?


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8704858.

Member

jmarshallnz commented Sep 19, 2012

The first 3 look fine. Not sure the 4th is needed - see my comment there.

On Thu, Sep 20, 2012 at 8:11 AM, Michal Piechowiak <notifications@github.com

wrote:

@jmarshallnz https://github.com/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?


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8704858.

@dersphere

This comment has been minimized.

Show comment
Hide comment
@dersphere

dersphere Sep 26, 2012

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 ;-)

Member

dersphere commented Sep 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@t-nelson

t-nelson Sep 26, 2012

Contributor

Yeah I saw this late last night and couldn't be arsed to hunt it at the
time. The resulting behavior is quite odd, anything from an assertion in
boost::shared_ptr::operator() to an empty scraper list. I'll try to take a
look tonight if pieh doesn't beat me to it.

On Wed, Sep 26, 2012 at 3:30 PM, Tristan Fischer
notifications@github.comwrote:

This causes issue #13351 (http://trac.xbmc.org/ticket/13351).
In short: "Choose a Scraper" and "Current Scraper" are empty in
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 ;-)


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8902164.

Contributor

t-nelson commented Sep 26, 2012

Yeah I saw this late last night and couldn't be arsed to hunt it at the
time. The resulting behavior is quite odd, anything from an assertion in
boost::shared_ptr::operator() to an empty scraper list. I'll try to take a
look tonight if pieh doesn't beat me to it.

On Wed, Sep 26, 2012 at 3:30 PM, Tristan Fischer
notifications@github.comwrote:

This causes issue #13351 (http://trac.xbmc.org/ticket/13351).
In short: "Choose a Scraper" and "Current Scraper" are empty in
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 ;-)


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1283#issuecomment-8902164.

LongChair added a commit to plexinc/plex-home-theater-public that referenced this pull request Aug 1, 2014

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment