WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
213967
[macOS 11] Indeterminate progress bar animation periodically jumps
https://bugs.webkit.org/show_bug.cgi?id=213967
Summary
[macOS 11] Indeterminate progress bar animation periodically jumps
Wenson Hsieh
Reported
2020-07-04 22:59:20 PDT
SSIA
Attachments
Patch
(1.65 KB, patch)
2020-07-04 23:04 PDT
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Patch
(9.77 KB, patch)
2020-07-05 10:53 PDT
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Wenson Hsieh
Comment 1
2020-07-04 23:04:49 PDT
Comment hidden (obsolete)
Created
attachment 403547
[details]
Patch
Sam Weinig
Comment 2
2020-07-05 06:38:34 PDT
Comment on
attachment 403547
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=403547&action=review
> Source/WebCore/rendering/RenderThemeMac.mm:128 > +#if HAVE(ALTERNATE_ICONS) > +static const double progressAnimationNumFrames = 120; > +#else > static const double progressAnimationNumFrames = 256; > +#endif
The CoreUI folks don't really want anyone using kCUIAnimationFrameKey, which is what requires us to know the number of frames. Can we instead switch to kCUIAnimationStartTimeKey/kCUIAnimationTimeKey and avoid the problem of needing to know the number of frames entirely?
Sam Weinig
Comment 3
2020-07-05 09:41:06 PDT
(In reply to Sam Weinig from
comment #2
)
> Comment on
attachment 403547
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=403547&action=review
> > > Source/WebCore/rendering/RenderThemeMac.mm:128 > > +#if HAVE(ALTERNATE_ICONS) > > +static const double progressAnimationNumFrames = 120; > > +#else > > static const double progressAnimationNumFrames = 256; > > +#endif > > The CoreUI folks don't really want anyone using kCUIAnimationFrameKey, which > is what requires us to know the number of frames. Can we instead switch to > kCUIAnimationStartTimeKey/kCUIAnimationTimeKey and avoid the problem of > needing to know the number of frames entirely?
An added benefit of this would be that if we use a shared heartbeat, all the indeterminate progress indicators in a page will animate in sync, just like in a normal app.
Wenson Hsieh
Comment 4
2020-07-05 10:29:34 PDT
Comment on
attachment 403547
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=403547&action=review
>>> Source/WebCore/rendering/RenderThemeMac.mm:128 >>> +#endif >> >> The CoreUI folks don't really want anyone using kCUIAnimationFrameKey, which is what requires us to know the number of frames. Can we instead switch to kCUIAnimationStartTimeKey/kCUIAnimationTimeKey and avoid the problem of needing to know the number of frames entirely? > > An added benefit of this would be that if we use a shared heartbeat, all the indeterminate progress indicators in a page will animate in sync, just like in a normal app.
Yep, this works great! I wish this meant we could just remove animationDurationForProgressBar and animationRepeatIntervalForProgressBar, but other ports (Adwaita?) seem to override this and return a non-zero value. That said, I can at least remove the hard-coded constants and stop overriding it in RenderThemeMac (and RenderThemeIOS as well, which for some reason overrides it but returns zero which is the default anyways 🤷🏻♂️).
Wenson Hsieh
Comment 5
2020-07-05 10:53:51 PDT
Created
attachment 403558
[details]
Patch
Sam Weinig
Comment 6
2020-07-05 11:53:57 PDT
Comment on
attachment 403558
[details]
Patch Very nice. We could probably optimize things a bit in the future (and make it match macOS a bit more) if we wanted by having a shared heartbeat timer for all indeterminate progress indicators, instead of using a timer per-RenderProgress.
Wenson Hsieh
Comment 7
2020-07-05 11:58:01 PDT
Comment on
attachment 403558
[details]
Patch (In reply to Sam Weinig from
comment #6
)
> Comment on
attachment 403558
[details]
> Patch > > Very nice. We could probably optimize things a bit in the future (and make > it match macOS a bit more) if we wanted by having a shared heartbeat timer > for all indeterminate progress indicators, instead of using a timer > per-RenderProgress.
Indeed!
EWS
Comment 8
2020-07-05 12:00:30 PDT
Committed
r263952
: <
https://trac.webkit.org/changeset/263952
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 403558
[details]
.
Radar WebKit Bug Importer
Comment 9
2020-07-05 12:01:16 PDT
<
rdar://problem/65109650
>
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