Flicker delays are specific to VariablesView consumers. See bug 808370.
Assignee: nobody → vporof
Status: NEW → ASSIGNED
Priority: -- → P3
Mihai, maybe you can use this directly in bug 808370 before landing it? :)
Attachment #718870 - Flags: review?(mihai.sucan)
Comment on attachment 718870 [details] [diff] [review] v1 Looks good. Thank you! Yet, I am not sure how long the delay should be for the web console. We shouldn't have to arbitrarily increase such delays to avoid flickers. Variables view should handle anti-flickering on its own.
Attachment #718870 - Flags: review?(mihai.sucan) → review+
(In reply to Mihai Sucan [:msucan] from comment #2) > > Yet, I am not sure how long the delay should be for the web console. We > shouldn't have to arbitrarily increase such delays to avoid flickers. > Variables view should handle anti-flickering on its own. As discussed on IRC, that's not really possible. Flickers are simply caused by the delay between an empty() call and the first scope/var/prop appending in the view. Because since there's no way for the view to know much time it may take between those two operations, it simply relies on a timeout to swap views, or "swap buffers" (the implementation is essentially just dumb double buffering). That said, we could enhance the current behavior to something like "yeah, delay the emptying, but flush/force redraw the contents as soon as the first thing was appended in the view". However, I think this is mostly engineering things and wouldn't result in drastic (or even measurable) improvements.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
You need to log in before you can comment on or make changes to this bug.