On 02/13/2013 07:55 PM, Boris Zbarsky wrote:
On 2/13/13 10:16 PM, Boris Zbarsky wrote:
On 2/13/13 9:47 PM, Brian Anderson wrote:
I haven't actually created a DOM-related milestone yet because we
haven't come up with a goal that I'm satisfied with ("create working
dom
bindings" is vague). Things we've considered as short-term bindings
goals are canvas and WebGL. Does anybody have suggestions here?
How about deciding on an actual implementation strategy for the DOM?
Note that from this point of view canvas and webgl are uninteresting
because they have only one DOM interface involved, so there are no
inheritance issues and whatnot.
A basic binding for Node that allows JS to do .firstChild without a
virtual function call on arbitrary nodes would be a lot more like what
I'm looking for here.
I understand your concern and I agree that validating the architecture
is our primary goal. Thank you for raising the subject. It is the first
thing mentioned on the roadmap on the wiki, but I neglected to consider
it when putting together these milestones.
So as you suggest, maybe we should tie some performance goals to the DOM
implementation. I've started by creating a new milestone that includes
the `firstChild` test and the issues that block it:
https://github.com/mozilla/servo/issues?milestone=3&state=open
The main performance issues that you've expressed concern about and that
I can recall are in the following issues:
* FFI stack switching - https://github.com/mozilla/servo/issues/278
* FFI virtual calls - https://github.com/mozilla/servo/issues/278
* DOM representation - https://github.com/mozilla/servo/issues/280
* string representation - https://github.com/mozilla/servo/issues/282
* optimizing layout requests - https://github.com/mozilla/servo/issues/283
3 of those are on the list for the new milestone. The string and layout
issues are not. Do you think it is appropriate to make either of those
part of the milestones for this year? Are there other critical
performance questions I'm forgetting?
I hope this helps ease your mind somewhat, but let me know if otherwise.
For your reference, some of the performance issues you've raised
previously are already impacting Rust's design. Most significantly the
[FFI] is in the process of being redesigned to support servo's use case.
Also, the upcoming [scheduler] redesign should give us more
opportunities to experiment with optimizations relevant to servo.
Regards,
Brian
FFI: https://github.com/mozilla/rust/issues/3678
scheduler: https://github.com/mozilla/rust/issues/4419
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
