Open
Bug 950791
Opened 11 years ago
Updated 2 years ago
Make incremental cycle collection use the NotifyDidPaint mechanism
Categories
(Core :: Cycle Collector, defect)
Core
Cycle Collector
Tracking
()
NEW
People
(Reporter: mccr8, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
This will reduce jankiness with animations and should be easy.
Reporter | ||
Updated•11 years ago
|
Assignee: nobody → continuation
Reporter | ||
Comment 1•11 years ago
|
||
The way this works for IGC is that running a normal slice of the GC locks out the NotifyDidPaint mechanism for the next frame, to prevent jankiness from running two slices too close together. Note that there is no lockout in the other direction: you can do some work with DidPaint, and then end up running a full slice before the next frame.
I'm not sure how well this will work for ICC, where we are trying to run a slice of work around every 15ms, which is about the same as the length of time between frames, so the regular slice work could end up just locking out the DidPaint work. It feels like what is needed is a way to sync up painting and ICC slices better.
Reporter | ||
Comment 2•11 years ago
|
||
This is a little tricker than I thought at first, so I think it can wait.
Reporter | ||
Comment 3•11 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Assignee: continuation → nobody
Updated•2 years ago
|
Severity: normal → S3
Reporter | ||
Updated•2 years ago
|
Component: XPCOM → Cycle Collector
You need to log in
before you can comment on or make changes to this bug.
Description
•