WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
74573
[chromium] DelayBasedTimeSource should not change its timebase on late ticks
https://bugs.webkit.org/show_bug.cgi?id=74573
Summary
[chromium] DelayBasedTimeSource should not change its timebase on late ticks
Nat Duca
Reported
2011-12-14 17:54:25 PST
[chromium] DelayBasedTimeSource should not change its timebase on late ticks
Attachments
Patch
(3.44 KB, patch)
2011-12-14 18:02 PST
,
Nat Duca
no flags
Details
Formatted Diff
Diff
Patch for landing
(8.07 KB, patch)
2011-12-15 19:12 PST
,
Nat Duca
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Nat Duca
Comment 1
2011-12-14 18:02:38 PST
Created
attachment 119353
[details]
Patch
Nat Duca
Comment 2
2011-12-14 18:29:04 PST
Grace, we should cherry pick this when it lands or whenever you feel you want it. It dramatically improves smoothness.
James Robinson
Comment 3
2011-12-14 20:14:39 PST
Comment on
attachment 119353
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=119353&action=review
logic looks reasonable, math could be tighter. i think you want something like if (newTickTarget <= now) newTickTarget += ceil((now - newTickTarget)/m_intervalMs) * m_intervalMs; although i haven't tested that. R=me on idea
> Source/WebCore/platform/graphics/chromium/cc/CCDelayBasedTimeSource.cpp:128 > // Here we realize we're more than a tick late. We adjust newTarget to be 16.667 from now, and post a task off that new > // target.
i _think_ you should update this bit of the comment as well
> Source/WebCore/platform/graphics/chromium/cc/CCDelayBasedTimeSource.cpp:143 > + while (newTickTarget <= now) > + newTickTarget = newTickTarget + m_intervalMs;
this should be a single multiplication instead of a loop this might give us really short delays (like 2ms). should we have a floor here, below which we push out to the next estimated vsync?
> Source/WebCore/platform/graphics/chromium/cc/CCDelayBasedTimeSource.cpp:148 > + if (!delay) { > + newTickTarget = newTickTarget + m_intervalMs; > + delay = static_cast<long long>(newTickTarget - now); > + }
i think you can get rid of this by being more careful with the math earlier
Nat Duca
Comment 4
2011-12-15 17:20:28 PST
Comment on
attachment 119353
[details]
Patch Incidentally, if I had cancellable tasks from trchen then I could post the task, then cancel it after running the tick to avoid pointless ticks. :>
James Robinson
Comment 5
2011-12-15 17:23:48 PST
I think you're joking, but I don't see what improvement that would bring - the task would still fire and it'd check a bit to see what to do (nothing). TANSTAAFL.
Nat Duca
Comment 6
2011-12-15 19:12:42 PST
Created
attachment 119541
[details]
Patch for landing
WebKit Review Bot
Comment 7
2011-12-16 00:24:01 PST
Comment on
attachment 119541
[details]
Patch for landing Rejecting
attachment 119541
[details]
from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 1 ERROR: /mnt/git/webkit-commit-queue/Source/WebCore/ChangeLog neither lists a valid reviewer nor contains the string "Unreviewed" or "Rubber stamp" (case insensitive). Full output:
http://queues.webkit.org/results/10902604
Nat Duca
Comment 8
2011-12-16 08:31:54 PST
Committed
r103070
: <
http://trac.webkit.org/changeset/103070
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug