- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 12 Jul 2013 05:28:56 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- CC: "www-style@w3.org" <www-style@w3.org>
> On 7/11/13 10:25 PM, François REMY wrote: >>> How do you determine that it has to be reevaluated? >> >> That's up to the browser to optimise that. > > Well, but ... that's the part that's typically "slow"! This is because it seems the goal has always been to narrow down to the smallest number of elements that may have been affected. For those complex selectors like "!abc ... def" that task is very hard indeed if def is a frequent tag. However, you can take a very different approach for them if you're not forced to be exact about them every time. For instance, let's say the author want the selector matching be accurate within 250ms, that leaves you 15 frames to accomplish the task. instead of optimising upfront you just queue all the possibly influenced elements in a list and you process them in a background thread asynchronously. The ones that are found to be actually affected by the 'slow selector' are marked for a true style resolution asap. So, a few frames might already have been rendered before the style resolution is really accurate, but that made it possible to use a difficult to live-update selector in a acceptably efficient way. The queue of elements to be considered can be pruned based on the results of the previous elements that were examined, and new elements may be added for evaluation during the course of the process if the DOM changes again.
Received on Friday, 12 July 2013 03:29:23 UTC