[dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)
https://github.com/mozilla/servo/wiki/Meeting-2014-03-24 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)
> > We have multiple layers support. I reworked because it was bogus, but it's > a hard problem with iframes in multiple threads Would it be helpful to explain how multiprocess layer trees work in Gecko? Very different than it was before because they're doing it without false > DOM nodes - all flow-based. > In the long run I'm quite sure you want to be using anonymous content for pseudoelements. Gecko used to render pseudoelements without creating anonymous content and that caused all sorts of problems. The trend for specs is to make the kinds of content you can create for pseudoelements richer, and to make pseudoelements expose APIs like regular DOM nodes (e.g. exposing GeometryUtils); so if you don't have real nodes underneath you'll just have ever more code duplication and pain. 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
Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)
On 3/24/14 1:40 PM, Robert O'Callahan wrote: We have multiple layers support. I reworked because it was bogus, but it's a hard problem with iframes in multiple threads Would it be helpful to explain how multiprocess layer trees work in Gecko? Sure, any info is helpful. Very different than it was before because they're doing it without false DOM nodes - all flow-based. In the long run I'm quite sure you want to be using anonymous content for pseudoelements. Gecko used to render pseudoelements without creating anonymous content and that caused all sorts of problems. The trend for specs is to make the kinds of content you can create for pseudoelements richer, and to make pseudoelements expose APIs like regular DOM nodes (e.g. exposing GeometryUtils); so if you don't have real nodes underneath you'll just have ever more code duplication and pain. That's what we're doing. "flow-based" was an inaccurate description. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)
On 3/24/14 1:41 PM, Patrick Walton wrote: That's what we're doing. "flow-based" was an inaccurate description. I should elaborate: what I was planning on doing is to have frame construction's notion of a DOM node be an abstraction that's either a real DOM node or a pseudo-element. That way all the code interacts with either DOM nodes or pseudo-elements equally, and we don't have to special-case them anywhere. I looked at the PR and it doesn't quite do this, so it'll have to be reworked. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)
On Tue, Mar 25, 2014 at 9:41 AM, Patrick Walton wrote: > On 3/24/14 1:40 PM, Robert O'Callahan wrote: > >> >>> We have multiple layers support. I reworked because it was bogus, but >>> it's >>> a hard problem with iframes in multiple threads >>> >> >> >> Would it be helpful to explain how multiprocess layer trees work in Gecko? >> > > Sure, any info is helpful. OK, so it's fairly obvious but it works well. Basically a process can construct RefLayers, which are a hole in the layer tree where another layer tree can be attached by the compositor. There is a global namespace of layer-tree IDs; when publishing a layer tree to the compositor, it's assigned an ID, and a RefLayer specifies the ID of the layer tree it should host. Before each composition, the compositor does a pass over the layer tree where it temporarily connects all the non-root layer trees as children of their RefLayers. There is no need for different processes to coordinate their layer tree update transactions in general. 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