I'd love to see us make some bold moves here for application development use cases (think asm.js for CSS.) Can we define a strict subset of CSS syntax with clear semantics for parallel processing, raster caches, hardware acceleration, and general app responsiveness?
--Jet ----- Original Message ----- From: "Boris Zbarsky" <[email protected]> To: [email protected] Sent: Friday, June 28, 2013 6:56:27 PM Subject: Re: [dev-servo] Selector matching in Rust On 6/28/13 4:58 PM, Simon Sapin wrote: > * Different rules can use the same selector. Map unique selectors each > to a list of rules, so that identical selectors do not need to be > matched more than once. That's an interesting idea; it's worth measuring how often this is useful in practice.... > * For each element in the document, possibly in parallel, find matching > selectors. The maps defined above allow rejecting quickly most selectors. The end goal is to end up with a (sorted in specificity order!) list of matching rules, not just the list of matching selectors. How to get there is an interesting question. > * There is a bloom filter for descendant combinators. I don’t understand > exactly how this works yet, but more code reading should fix that. Reading https://bugzilla.mozilla.org/show_bug.cgi?id=705877 (note comment 0, comment 5), might be simpler, or at least worth doing before reading code. > Did I miss something important? We need to think about what the in-memory representation of selectors will be. We're not happy with Gecko's, in particular: it's pointer-chasey and malloc-happy. This can be rejiggered as needed at a later point, probably, depending on what exactly we're using selectors for. > Perhaps more tricky is dynamic changes (in stylesheets, in DOM tree, > etc.) Should we consider as soon as now how to make them fast in > selector matching? If you haven't read https://wiki.mozilla.org/Servo/StyleUpdateOnDOMChange you probably should... In particular, one of the hard bits with parallel selector matching is that selector matching needs to store deoptimization flags on DOM nodes or something attached to them or something to make dynamic changes fast. So to that extent, you need to consider dynamic changes when designing selector matching. > Would it help to have a video / whiteboard discussion of all this? I want to say yes, but we should have a plan for what we want to discuss, so we don't get sidetracked on things like the selector in-memory representation, say... -Boris _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
