On Thu, Feb 6, 2014 at 5:09 AM, Josh Matthews <j...@joshmatthews.net> wrote:
> https://github.com/mozilla/servo/wiki/Meeting-2014-02-03 > > - pcwalton: that's how gecko does it, but the FrameLayerBuilder is > really complicated. Roc is the only one who understands how that works, so > should probably not do that. But if we can save in allocations, we should > definitely do that. But we can probably use smallvec optimizations, etc. > > Not really true; Matt Woodrow understands it well, and and I think Timothy Nikkel most of it too. But I think it's very likely that for performance and simplicity you might be better off going with a more static layer assignment like Webkit's, as I think Patrick was suggesting. Some of our design decisions were driven by a desire to ensure that if you have elements A, B and C in that z-order, but B and C don't overlap, then we can place A and C in the same layer if they're both static. This can reduce layer buffer usage in some common situations (e.g. B is a <video>, A is the page background and C is content after the <video>). Also, it lets C get subpixel-antialising better and more easily since the A-C layer will typically be opaque. If you give up on subpixel-AA (I think you should, because high-DPI displays are the future), that's not relevant to you. And it's unclear how much the memory usage matters. As an aside, before I forget, a thing to think about is "active" vs "inactive" layers. The idea is that some layer subtrees can be flattened to a single buffer because although they use compositor effects (opacity, transforms, etc) they're not really changing. Currently we do this in FrameLayerBuilder and it adds a bunch of complexity there. You're probably better off not doing that, tagging your inactive layer subtrees, and having the compositor cache the composition of the composited subtree (and ideally discard the backing storage of the individual layers in those subtrees). Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
