Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

[fix] - fix the autoclose timeout calculation - using SystemClockMillis #778

Merged
merged 1 commit into from

4 participants

@Memphiz
Owner

I got problems with the yesno dialog which is shown after resolution switching in iOS. When using the old timeout implementation based on GetFrameTime, that dialog doesn't even show up because it timed out before.

I added 2 printouts for verification of the old, wonky behaviour:

GUIDialog.cpp:L99: i logged the m_showStartTime here

GUIDialog.cpp:L229: i logged the m_showStartTime + m_showDuration < TimeUtils::GetFrameTime() here.

This is the printout:

http://pastebin.com/tmwW98YP

As you can see the timeout is 10 secs for that yesno dialog. And XBMC eats that 10 secs up in no time. Time traveling?

No sure if the switch to SystemClockMillis is the right fix here. You can't test with this special dialog because resolution/monitor switching is not in mainline yet.

@jimfcarroll
Collaborator

I don't think that's quite right. On windows SystemTimeMillis can wrap. If you're trying to check that a certain duration has gone by use the EndTime class in threads/SystemClock.h - the comment has an explanation.

@davilla

if GetFrameTime is misbehaving on ios, that need to get fixed as it is used elsewhere.

@jmarshallnz
Owner

If it takes ~10 seconds to switch resolutions (your log doesn't go back far enough to verify this) then this would be expected. GetFrameTime() returns the projected next frame time which is based off the last call to UpdateFrameTime(). If this was 10 seconds ago (i.e. the main thread has not rendered for 10 seconds due to it farting around switching resolutions) then this is to be expected.

An alternate fix might be in CGUIDialog::DoProcess() check whether we've rendered or not yet and set the show time there:

if (!HasRendered())
m_showStartTime = currentTime;

@Memphiz
Owner

indeed switching display on ios can last 10secs on my slow display. I don't get a callback when its really finished switching so i have 2secs fadeout + 6 secs worst case switching time + 2 secs fade in ... all in all 10 secs ... will test the other approach then...

@Memphiz
Owner

Updated the PR. I don't think basing the AutoClose timing in the GUIDialog on GetFrameTime is the right thing to do then, when it depends on when we rendered last. So i've done the EndTime approach here. (JM your suggestion didn't work either).

Pretty straight forward i think :)

@jmarshallnz
Owner

Why didn't it work?

@Memphiz
Owner

I don't know. I just gave it a quick shot and it didn't do it. I didn't investigate any further because i already felt that basing the timeout on GetFrameTime here is not the right thing to do. Are you of another opinion here? Or just curious why it didn't work?

@jmarshallnz
Owner

Both - once rendered, the frame timer should essentially be the same.

@Memphiz
Owner

sigh ;)

@Memphiz
Owner

I find the code much cleaner by using that nice EndTime class jimfcarroll did. (last try)

@Memphiz
Owner

So i gave it another shot. It doesn't work with setting showstarttime in doprocess. Since i just don't get how this is supposed to fix the issue. Could you just add a 10 secs sleep in WinSystemOSX.mm:629 and reproduce my problem and help me out?

@jmarshallnz
Owner

I'll see if I have time to take a look tonight.

@jmarshallnz jmarshallnz was assigned
@Memphiz
Owner

Thx jm your fix worked only once - so i added a "m_showStartTime = 0;" into DoModal_Internal (in your name as i've squashed the commits) - because the dialog is reused as it seems. Works now. What do you think?

@jmarshallnz
Owner

Hmm, yes, it will need resetting - I only tested it once :p. I'd do it in GUI_MSG_WINDOW_INIT I think (where the previous code was to set it to the frametime).

@Memphiz
Owner

done ...

Jonathan Marshall fix dialog autoclose by ensuring the timer starts only once we've ren…
…dered once (frametime is then accurate)
06d83a9
@jmarshallnz jmarshallnz merged commit cbd97ea into xbmc:master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 31, 2012
  1. @Memphiz

    fix dialog autoclose by ensuring the timer starts only once we've ren…

    Jonathan Marshall authored Memphiz committed
    …dered once (frametime is then accurate)
This page is out of date. Refresh to see the latest.
Showing with 16 additions and 3 deletions.
  1. +16 −3 xbmc/guilib/GUIDialog.cpp
View
19 xbmc/guilib/GUIDialog.cpp
@@ -35,6 +35,8 @@ CGUIDialog::CGUIDialog(int id, const CStdString &xmlFile)
m_wasRunning = false;
m_renderOrder = 1;
m_autoClosing = false;
+ m_showStartTime = 0;
+ m_showDuration = 0;
m_enableSound = true;
}
@@ -97,7 +99,7 @@ bool CGUIDialog::OnMessage(CGUIMessage& message)
case GUI_MSG_WINDOW_INIT:
{
CGUIWindow::OnMessage(message);
- m_showStartTime = CTimeUtils::GetFrameTime();
+ m_showStartTime = 0;
return true;
}
}
@@ -226,8 +228,19 @@ void CGUIDialog::Show()
void CGUIDialog::FrameMove()
{
- if (m_autoClosing && m_showStartTime + m_showDuration < CTimeUtils::GetFrameTime() && !m_closing)
- Close();
+ if (m_autoClosing)
+ { // check if our timer is running
+ if (!m_showStartTime)
+ {
+ if (HasRendered()) // start timer
+ m_showStartTime = CTimeUtils::GetFrameTime();
+ }
+ else
+ {
+ if (m_showStartTime + m_showDuration < CTimeUtils::GetFrameTime() && !m_closing)
+ Close();
+ }
+ }
CGUIWindow::FrameMove();
}
Something went wrong with that request. Please try again.