Re: [dev-servo] Meeting notes - further discussion of selected topics from Unanswered questions thread
On 7/15/13 3:05 PM, Josh Matthews wrote: https://github.com/mozilla/servo/wiki/Meeting-2013-07-15 Some comments on the discussion (sorry I couldn't make the meeting, and thank you for the notes!): 1) Mutable prototypes will be supported in SpiderMonkey (and indeed are), but they will likely not be fast (and indeed, they are not). For one thing, they totally defeat the way TI works right now. In practice, we should check how often C++ objects are allocated without setting up their proto chain in Gecko. I bet it's not too often If we get desperate here, we can try to make DOM prototype setup faster in SpiderMonkey. Right now it's slow mostly for dumb reasons. Or are we worrying about the memory used by the prototypes? 2) We can modify Spidermonkey as needed, and should, but we also want to avoid biting off more than we can chew (e.g. replacing TI wholesale is probably not something that should be on the blocking path to servo). Especially given that the JS team doesn't have spare cycles. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from Unanswered questions thread
people like roc say we must be at least as fast as Gecko for everything To be clear: I think Servo's architecture must not prevent Servo from being as fast as Gecko for everything. I push for microbenchmarks targeting the risky parts of Servo's architecture because we must avoid discovering much later that some critical part of Servo's architecture is wrong. But I think it's completely fine for Servo to be slower than Gecko on some tests, indefinitely, as long as it's obvious how to fix that. In fact it's much more important to beat Gecko (and Blink) mightily on some tests than to equal them on all tests. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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] Meeting notes - further discussion of selected topics from Unanswered questions thread
For compositing with IFRAMEs, you might want to consider what we do for multi-process compositing in Gecko. It's somewhat obvious but it seems like it works well. Each process publishes a layer tree to the compositor. A layer tree can contain RefLayers, each with a unique ID. A layer tree root can also be given an ID. The compositor matches roots to RefLayers to build a complete layer tree which is composited as a whole. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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] Safe abstractions for unique handles
On 7/15/13 4:32 PM, Robert O'Callahan wrote: A minor random thought related to that design: Using integer IDs, as Gecko does, raises the possibility of a bug, possibly even a security bug, where a rogue IFRAME is able to render itself at the wrong place in the tree. In Gecko, preventing a compromised process from doing an attack like that requires explicit code to track which IDs have been issued to a process and checking to make sure it doesn't use an ID we didn't give it. Obviously it would be much better to use an object-capability approach, but of course we can't do that in Gecko. So it would be nice if Rust+Servo can provide a robust cross-task object-capability-ID abstraction for use in situations like this. Right, that's been on our mind as well. We try to use channels and ports wherever we can. In general channels and ports are better than IDs in every way: they cannot be forged and have better memory management properties (as integer IDs can't really be reference counted). Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
