In Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp:ChromeClient::paint. There has check timeUntilNextDisplay > 0 to reduce the no necessary painting, but you forget to check timeSinceLastDisplay's value can be an minus!!! please add this code before " if (timeUntilNextDisplay > 0) { " ------------------------------------------------------------- if (timeSinceLastDisplay < 0) { // We can go back to the past in computer World:) timeUntilNextDisplay = 0; } ------------------------------------------------------------------
Do you have a reproducible test case that shows the problem? Technically, timeSinceLastDisplay can end up being negative, but it would in the worst case simply cause skipping one paint (dropping a frame). This can be avoided by using WTF::monotonicallyIncreasingTime() instead of WTF::currentTime().
reproducible test case is very easy set the system time go back to past
It's not only dropping one frame, it freeze the whole GUI rendering!!!(only webkitgtk, qtwebkit hasn't this problem) You can run any GUI program based on webkitgtk and then adjust system time go back one hour(or more) then any GUI is freeze. (In reply to comment #1) > Do you have a reproducible test case that shows the problem? > > Technically, timeSinceLastDisplay can end up being negative, but it would in the worst case simply cause skipping one paint (dropping a frame). > This can be avoided by using WTF::monotonicallyIncreasingTime() instead of WTF::currentTime().
m_lastDisplayTime = currentTime() is update too later! (so used m_lastDisplayTime and update it immediately is a good idea) So "double timeSinceLastDisplay = currentTime() - m_lastDisplayTime" timeSinceLastDisplay is always an very big negative number ( minus 3000+ is we go to past one hour) until one hour past! (In reply to comment #1) > Do you have a reproducible test case that shows the problem? > > Technically, timeSinceLastDisplay can end up being negative, but it would in the worst case simply cause skipping one paint (dropping a frame). > This can be avoided by using WTF::monotonicallyIncreasingTime() instead of WTF::currentTime().
(In reply to comment #3) > It's not only dropping one frame, it freeze the whole GUI rendering!!!(only webkitgtk, qtwebkit hasn't this problem) Yeah, I was wrong - didn't thought of the possibility of changing the system date to irrational values. (In reply to comment #4) > m_lastDisplayTime = currentTime() is update too later! (so used m_lastDisplayTime and update it immediately is a good idea) That part is just fine - m_lastDisplayTime is assigned the new value when the last display is actually complete.
Created attachment 209224 [details] Patch
Comment on attachment 209224 [details] Patch Clearing flags on attachment: 209224 Committed r154380: <http://trac.webkit.org/changeset/154380>
All reviewed patches have been landed. Closing bug.