Re: [dev-servo] Omar Mozilla Intern Introduction

[Robert O'Callahan]

On Wed, Jun 5, 2019 at 4:16 AM Alan Jeffrey  wrote:

> We're interested in doing the experiment of how to increase the amount of
> determinism in a program like Servo where almost all the nondeterminism
> that's observable by Servo has a single cause (in Servo's case selecting on
> channels). There'll still be a lot of nondeterminism in the system (e.g.
> dependencies like rayon that do their own thread management) but hopefully
> not much that's observable within Servo, and in particular not much that
> causes intermittent WPT test failure. If this experiment works, there's
> then the question of what the overhead is compared to something like rr, my
> guess is that it'll be lower, but rr is very very good at its job, so it
> may be a hard target to beat!
>

I think you'll easily beat rr overhead if your hypothesis is correct and
recording channel nondeterminism suffices to make replay actually work ---
even ignoring parallelism.

It sounds like a great experiment and it'll be interesting to see how that
works out!

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Omar Mozilla Intern Introduction

[Robert O'Callahan]

On Tue, Jun 4, 2019 at 11:49 AM Omar Salvador Navarro Leija <
ole...@mozilla.com> wrote:

> This summer, I will be looking at taming a small piece of the difficulty
> with debugging parallel systems. Specifically, implementing
> record-and-replay for Rust channels. This will hopefully make servo a
> little easier to debug and a little more deterministic :)
>

What's the motivation for doing this vs using an off-the-shelf record and
replay tool like rr? Ability to handle multicore parallelism? Ability to
work on non-Linux?

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo testing as part of PhD dissertation

[Robert O'Callahan]

On Thu, Sep 8, 2016 at 4:12 AM, Lars Bergstrom  wrote:

> Along those lines, it's also worth looking at the very recent awesome
> work at the University of Washington formalizing layout (upcoming
> paper at OOPSLA):
> http://cassius.uwplse.org/
>

> I've been in contact with them with the hopes of trying it out in the
> context of Servo, as I believe there are both some interesting testing
> applications and some really nifty things that we could do with
> devtools using such a tool, too.
>

Cassius doesn't support any kind of fragmentation, not even line breaking,
and they look difficult to add to the Cassius model. But it does look cool
for the sort of testcases gsnedders was talking about.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposal: TLS library for Servo

[Robert O'Callahan]

On Thu, Sep 1, 2016 at 12:57 PM, Diane Hosfelt  wrote:

> Right now, what I’m working on is updating some TLS statistics using
> https://github.com/mozilla/cipherscan  cipherscan> (it’s taking a bit longer than I’d originally anticipated).
> Based on my current results (~50k sites), over 7% can only use TLS1 or
> lower. This means that, at a minimum, rustls would need need to implement
> TLS1 and 1.1 in addition to 1.2 (and eventually 1.3) in order for Servo to
> use it. I’m not quite sure what the bar should be for deciding that it’s
> okay to not support legacy protocols, but I definitely think that 7% is too
> high. In my opinion, web compatibility should be a goal of Servo.
>

FWIW, while I agree with that, I think it's important to get key
high-volume sites working well in Servo --- Facebook, GMail, Youtube,
Yahoo, Twitter, Amazon, etc --- before tackling the "long tail". I assume
the former do not require TLS < 1.2. That gives you plenty of time to add
TLS < 1.2 to rusttls.

One question I haven't seen asked or answered yet is whether the rusttls
maintainers would accept contributions to make it Web-compatible, and if
not, how one would maintain a Web-compatible version of it.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

[Robert O'Callahan]

On Thu, Aug 4, 2016 at 4:47 AM, Andrew McCreight 
wrote:

> If you do want to think about it, I'd first read over the work that Chrome
> people have already put into thinking about this issue:
> http://www.chromium.org/developers/design-documents/site-isolation
>
> I'm not sure how much they have actually shipped from this initiative,
> though.
>

Neither do I, but I do know they've been working on it for many years and
it's really, really hard, at least in legacy code like Chromium. As of 18
months ago, Chrome devs were designing new features without necessarily
taking site isolation into account.

The question is, how hard would it be to support full site isolation in
Servo at this point? If not hard, then it's probably worth maintaining at
least as an optional feature for scenarios with abundant memory and maximal
security requirements (which, in the future, could be "everyone"). If it is
hard, consider giving it up and relying on Rust as the only line of defense
between different origins in the same toplevel browsing context.

(Supporting multiple content processes like the other browsers already do
seems like a no-brainer given that it doesn't add much complexity.)

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

[Robert O'Callahan]

On Wed, Aug 3, 2016 at 4:10 PM, Michael Howell 
wrote:

> I can think of one advantage right now: by having script and layout in
> separate processes, a compromised script thread doesn't automatically give
> an attacker the ability to produce malformed display lists that draw
> outside the tab boundary.
>

Seems to me this can easily be prevented by clipping the display lists
produced by content layout.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?

[Robert O'Callahan]

On Tue, Jun 21, 2016 at 9:16 AM, Jack Moffitt  wrote:

> > The problem is that you want notifications ahead of time that an element
> is
> > predicted to become visible, so you can decode images/video etc hopefully
> > in time to render the element the moment it becomes visible.
>
> Does this mean you need scroll velocity and other such data to make
> such a prediction?
>

Yes.


> > It's implemented as a seek operation, so you decode a keyframe and then
> as
> > many frames as necessary to reach the nominal current position.
>
> Does this mean it doesn't work for live video sources or MSE?
>

I don't know. Dan Glastonbury or Anthony Jones are on the video side,
Timothy Nikkel and Seth Fowler are on the layout/image rendering side.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to efficiently react to an element changing visibility status from DOM code?

[Robert O'Callahan]

On Tue, Jun 21, 2016 at 4:41 AM, Jack Moffitt  wrote:

> How is this done in Gecko?
>

Display list analysis in the main thread.

We learn something is not visible during one of the various cullings
> of WebRender. So I guess the idea would be to have some notification
> you send when something goes from visible previously to invisible. I
> suppose there is an analog when doing flow construction that you might
> find a flow that was previously visible is now display: none.
>

The problem is that you want notifications ahead of time that an element is
predicted to become visible, so you can decode images/video etc hopefully
in time to render the element the moment it becomes visible.

One issue that wasn't covered in that lightning talk is that what
> happens when the video comes back into view? Decoding can only be
> started at a keyframe, so how do they resume playback?
>

It's implemented as a seek operation, so you decode a keyframe and then as
many frames as necessary to reach the nominal current position.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] MathML

[Robert O'Callahan]

Don't quote me on this, but Mathjax is moving away from MathML which means
MathML support in browsers is effectively a lost cause at this point. Don't
even think about doing it.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Student Project

[Robert O'Callahan]

On Mon, Jan 11, 2016 at 7:04 AM, Nicolas Silva 
wrote:

> Anyone interested in implementing WebAudio and/or WebRTC (in Gecko
> there's some overlap in the underlying infrastructure) should first
> spend some time discussing the architecture with Paul Adenot (look for
> padenot on irc). Having a competitive or even just decent WebAudio
> implementation is more complex than it looks, and Gecko's implementation
> had to go through massive rewrites before it got to a satisfying place.
> According to Paul it's not the kind of architecture one gets right the
> first time without some serious experience in audio engines.
> That said, it would be great to have a WebAudio implementation in rust,
> and I am sure the rust gamedev community would be thrilled to have
> something like this!
>

Right.

You'd really want to study the architecture of Gecko's implementation and
understand why it is the way it is before attempting this. You'd also want
to understand the architectural changes we're still planning to make. Paul
and I can help with this.

In Gecko MediaStreams and WebAudio are integrated into a single real-time
media graph (well, multiple graphs, one per logical output channel), which
has advantages but means you're designing more than just WebAudio.

If we did have a good WebAudio implementation in Servo it's one piece I
could imagine sharing with Gecko. But it's a lot of work to get to parity.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] IndexDB project

[Robert O'Callahan]

Jan Varga and others are currently reworking all client-side persistent
storage APIs in Gecko so they can all use common quota management. You
might want a similar framework in Servo now so you don't have to do a lot
of expensive work later.

You should talk to him or Kyle Huey or others on the Gecko side; I'm sure
they have a lot of information that would be useful.

FWIW I think this project falls into the category of "things we know will
work in Servo". It might be more valuable to do a project from which we
would learn more.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] IndexDB project

[Robert O'Callahan]

On Tue, Dec 15, 2015 at 12:33 AM, Paul Rouget <p...@mozilla.com> wrote:

> On Tue, Dec 15, 2015 at 5:27 AM, Manish Goregaokar
> <manishsm...@gmail.com> wrote:
> > On Tue, Dec 15, 2015 at 9:39 AM, Robert O'Callahan <rob...@ocallahan.org
> >
> > wrote:
> >
> >>
> >> FWIW I think this project falls into the category of "things we know
> will
> >> work in Servo". It might be more valuable to do a project from which we
> >> would learn more.
> >
> >
> > We should probably start implementing necessary things too, not only
> > focusing on new experiments :)
>
> And browser.html needs persistent storage.
>

Doesn't browser.html also need ServiceWorkers? ServiceWorkers has
significant architectural impact, and its own Cache storage API, so I think
that's pretty interesting :-).

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Stacking order of inline stacking contexts

[Robert O'Callahan]

On Fri, Nov 6, 2015 at 12:53 PM, Martin Robinson 
wrote:

> By way of example:
>
> 
> 
> Line 1
> Line 2
> 
> 
>
> The two spans are inline, so normally "Line 1" would stack underneath
> "Line 2" due to tree order. Since "Line 1" establishes a stacking
> context (via the opacity style property), it stacks in tree order with
> the divs (which also establish stacking contexts via their transform
> style properties). The way I implement this is to always insert inline
> stacking contexts into the positioned content section of the display list.
>

That's right.


> The issue I'm having now is that I cannot figure out where or how this
> behavior is described in the spec [1][2]. Both the divs and the first
> span seem to be treated as "positioned descendants" as described in
> Section E.2.8.
>
> I still plan to implement the same behavior as Gecko and Chrome, but I
> would be very grateful is someone could help shed light on how this
> relates to the spec. Thanks!
>

Yeah, it's not in Appendix E, though it probably should be. For 'opacity'
this is described in the CSS3 Color spec:
http://www.w3.org/TR/css3-color/#transparency

> If an element with opacity less than 1 is not positioned, implementations
> must paint the layer it creates, within its parent stacking context, at the
> same stacking order that would be used if it were a positioned element with
> ‘z-index: 0’ and ‘opacity: 1’.
>
All properties that induce a stacking context behave this way.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Robert O'Callahan]

On Thu, Nov 5, 2015 at 12:44 AM, James Graham <ja...@hoppipolla.co.uk>
wrote:

> On 04/11/15 11:41, Robert O'Callahan wrote:
>
>> The media tests are better than I thought --- I found more. They don't
>> test
>> the variety of problematic media files that our mochitests do, but maybe
>> that's not in scope? Should we be worried that regressions in the media
>> stack seldom trigger W test failures on mozilla-inbound but often trigger
>> mochitest failures?
>>
>
> I consider anything that might affect browser interop or quality in-scope,
> as long as it can be run cross-browser and it's clear what the expected
> result is.


OK: https://github.com/w3c/web-platform-tests/issues/2305

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Robert O'Callahan]

On Thu, Nov 5, 2015 at 12:17 AM, James Graham <ja...@hoppipolla.co.uk>
wrote:

> On 04/11/15 11:12, Robert O'Callahan wrote:
>
>> Well sure, I agree that taking mochitests as the input to a test-writing
>>> effort is a good idea. I see this as being very different to blindly
>>> shimming mochitests into the wpt harness. Having said that, however, I
>>> don't think people have complained a lot about lack of test coverage from
>>> wpt except in the areas that it doesn't cover at all i.e. dynamic changes
>>> to layout, or other human interaction.
>>>
>>
>>
>> To pick a couple of areas I work on: for CSSOM-Views for example there is
>> practically no coverage at all. The media tests are better but still very
>> limited compared to what we test in mochitests.
>>
>
> It would be great to have a record of some areas where we know that
> web-platform-tests has missing coverage; we occasionally get people looking
> for areas where they can make useful test contributions and asking what's
> required. Can you file some issues on GitHub, possibly pointing to the
> relevant mochitests that we could draw from?


Sure. https://github.com/w3c/web-platform-tests/issues/2304

The media tests are better than I thought --- I found more. They don't test
the variety of problematic media files that our mochitests do, but maybe
that's not in scope? Should we be worried that regressions in the media
stack seldom trigger W test failures on mozilla-inbound but often trigger
mochitest failures?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Robert O'Callahan]

On Wed, Nov 4, 2015 at 5:14 PM, James Graham <ja...@hoppipolla.co.uk> wrote:

> On 03/11/15 22:08, Robert O'Callahan wrote:
>
> Why not create a Mochitest compatibility layer over testharness.js so
>> that tests that only use SimpleTest.waitForExplicitFinish(),
>> SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial
>> changes?
>>
>
> A few reasons I am skeptical of this:
>
> * Mochitests test gecko behaviour, not standardised behaviour. These can
> and do differ. Therefore they are even less trustworthy than the average
> test.
>

I'm not sure what you mean by this. It's easy to write web-platform-tests
that depend on non-standard behavior. I had to debug one such last week.
Furthermore Gecko mochitests have been tested against Gecko, which has
itself been tested on the Web, so Gecko mochitests are far more likely to
be "correct" than a test someone just wrote and only tested on, say, Servo.

* Mochitests are really written assuming the full gecko featureset. Given
> the total lack of isolation between asserts, they may behave rather
> unexpectedly and misleadingly in a browser not having all those features.
>

Many use Gecko-specific features but many don't.

* In the long term having multiple APIs for writing tests that people have
> to learn in order to read tests is a big net negative. If we allow
> mochitests to be upstreamed with a shim we should expect other vendors to
> do the same, and to end up with half a dozen possible test formats.
>

That's fair, though it's a problem we introduced when we started adding
web-platform-tests to the tree.

Put it this way: when Servo needs tests for a feature, I expect it makes
much more sense to take Gecko mochitests for the feature and convert them
to web-platform-tests than to write new tests from scratch.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Robert O'Callahan]

On Wed, Nov 4, 2015 at 11:50 PM, James Graham <ja...@hoppipolla.co.uk>
wrote:

> On 04/11/15 10:24, Robert O'Callahan wrote:
>
>> On Wed, Nov 4, 2015 at 5:14 PM, James Graham <ja...@hoppipolla.co.uk>
>> wrote:
>>
>> On 03/11/15 22:08, Robert O'Callahan wrote:
>>>
>>> Why not create a Mochitest compatibility layer over testharness.js so
>>>
>>>> that tests that only use SimpleTest.waitForExplicitFinish(),
>>>> SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial
>>>> changes?
>>>>
>>>>
>>> A few reasons I am skeptical of this:
>>>
>>> * Mochitests test gecko behaviour, not standardised behaviour. These can
>>> and do differ. Therefore they are even less trustworthy than the average
>>> test.
>>>
>>>
>> I'm not sure what you mean by this. It's easy to write web-platform-tests
>> that depend on non-standard behavior. I had to debug one such last week.
>> Furthermore Gecko mochitests have been tested against Gecko, which has
>> itself been tested on the Web, so Gecko mochitests are far more likely to
>> be "correct" than a test someone just wrote and only tested on, say,
>> Servo.
>>
>
> I mean that mochitests are used as regression tests; they aren't
> necessarily testing the per-spec behaviour (which might match Blink or
> Edge, but not Gecko), but whatever the Gecko code implements. Of course
> web-platform-tests can be buggy like any other code, but they are at least
> intended to test the right thing.


I think it's uncommon for mochitests to intentionally be stricter than what
the spec requires ... excluding cases where the spec is known to be
inadequate. It's easy to be accidentally more strict, but that's true for
WPT too.


> * Mochitests are really written assuming the full gecko featureset. Given
>>
>>> the total lack of isolation between asserts, they may behave rather
>>> unexpectedly and misleadingly in a browser not having all those features.
>>>
>>>
>> Many use Gecko-specific features but many don't.
>>
>
> Not just use of gecko-specific (or, often spidermonkey-specific)
> behaviours, but also the fact that mochitests assume an assert never fails
> (because if one does it's a regression that needs to be fixed). In Servo,
> which might not implement all the features used, an assert can be expected
> to fail for some time until more feature work is done. This is particularly
> true at the moment when Servo doesn't implement the window error handler. I
> anticipate this impedance mismatch would cause the tests to be less useful
> in Servo than they are in Gecko.
>

That makes sense.


>
> * In the long term having multiple APIs for writing tests that people have
>>
>>> to learn in order to read tests is a big net negative. If we allow
>>> mochitests to be upstreamed with a shim we should expect other vendors to
>>> do the same, and to end up with half a dozen possible test formats.
>>>
>>>
>> That's fair, though it's a problem we introduced when we started adding
>> web-platform-tests to the tree.
>>
>> Put it this way: when Servo needs tests for a feature, I expect it makes
>> much more sense to take Gecko mochitests for the feature and convert them
>> to web-platform-tests than to write new tests from scratch.
>>
>
> Well sure, I agree that taking mochitests as the input to a test-writing
> effort is a good idea. I see this as being very different to blindly
> shimming mochitests into the wpt harness. Having said that, however, I
> don't think people have complained a lot about lack of test coverage from
> wpt except in the areas that it doesn't cover at all i.e. dynamic changes
> to layout, or other human interaction.


To pick a couple of areas I work on: for CSSOM-Views for example there is
practically no coverage at all. The media tests are better but still very
limited compared to what we test in mochitests.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Robert O'Callahan]

On Tue, Nov 3, 2015 at 10:10 PM, James Graham 
wrote:

> On 02/11/15 18:43, Josh Matthews wrote:
>
>> https://github.com/servo/servo/wiki/Meeting-2015-11-02
>>
>
> For the record, I'm very against trying to run mochitests in Servo. As I
> understand it the additional features it offers over wpt are mostly because
> it leverages gecko-internal APIs that Servo doesn't support.


We have a ton of mochitests that either don't use special APIs at all, or
do so only in very limited ways. There's a lot of value in those tests that
I'd hate to just leave behind.

Why not create a Mochitest compatibility layer over testharness.js so that
tests that only use SimpleTest.waitForExplicitFinish(),
SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial
changes?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Robert O'Callahan]

On Wed, Nov 4, 2015 at 1:48 PM, Manish Goregaokar 
wrote:

> That sounds like a good idea. Perhaps we should do this on the
> mozilla-central side; move things out of mochitest into WPT?
>
> Is there an easy way of identifying browser-agnostic mochitests?
>

Maybe grepping for the obvious showstoppers (SpecialPowers, EventUtils.js)
and just trying to run the rest...

Regexp-based mass conversion might be reasonable too, with some human
review.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] WebRender

[Robert O'Callahan]

This sounds very promising!

A question: one of the graphs shows Servo taking 35ms per frame to paint
the slide-in animation. What exactly is in this animation that makes it
take such a relatively long time to paint?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 8/10 (retrying PRs; UA string; e10s; WebAudio preliminaries; demos; IndexedDB preliminaries)

[Robert O'Callahan]

On Mon, Aug 10, 2015 at 1:52 PM, Josh Matthews j...@joshmatthews.net
wrote:

 https://github.com/servo/servo/wiki/Meeting-2015-08-10


Before you run ahead and implement WebAudio, I suggest talking to Paul
Adenot or me about your design. We learned a lot from our implementation.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 7/27 (critic, e10s, hyper, builders)

[Robert O'Callahan]

Why can't you debug with sandbox enabled?

Seems to me Rust needs to be able to build with optimizations and debugging
diagnostics both enabled, and that's how you should run Servo tests. C++
can, and we rely on that on mobile for Gecko.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Per-document event queues

[Robert O'Callahan]

On Fri, Jul 24, 2015 at 10:26 AM, Josh Matthews j...@joshmatthews.net
wrote:

 I don't believe anybody has put thought into addons beyond something like
 Chrome at this point.


FWIW https://bugzilla.mozilla.org/show_bug.cgi?id=1161828

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 7/6 (Reviewable; benchmarking DOM/layout interaction; Rust/Servo training materials)

[Robert O'Callahan]

The layout engine synthesis ideas might pay off for the compute just this
metric problem.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Multiprocess safety

[Robert O'Callahan]

On Fri, Jun 19, 2015 at 12:45 PM, Patrick Walton pwal...@mozilla.com
wrote:

 It's fine to pass channels over channels as long as those channels don't
 cross process boundaries.


Out of interest, why can't you pass channels over channels across a process
boundary?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Multiprocess safety

[Robert O'Callahan]

On Fri, Jun 19, 2015 at 7:10 PM, Patrick Walton pwal...@mozilla.com wrote:

 In theory you can use cmsg on POSIX systems to send channels over
 channels, by treating channels as file descriptors. I tried this first, and
 I believe it actually worked well on Linux. But on Mac I ran into all sorts
 of (as far as I can tell) kernel bugs, including kernel panics and data
 loss. It might still be possible by using Mach ports instead on the Mac
 (and I started to sketch that code), but I eventually figured it was going
 to be cleaner to just stop sending channels over channels across process
 boundaries.


Firefox IPDL sends file descriptors over sockets on Mac using cmsg. There
is a kernel bug where an in-flight file descriptor is not kept open by the
kernel, so you must keep it open on the sender side until the message is
acknowledged. I don't know about any kernel panics related to that feature.

On Windows you should be able to rig something up using DuplicateHandle. I
think Firefox uses this on Windows but I'm not sure.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)

[Robert O'Callahan]

On Tue, Apr 28, 2015 at 7:32 PM, Manish Goregaokar manishsm...@gmail.com
wrote:

 But I think that as long as the glove still fits, we should use it.
 Perhaps reevaluate when we start shipping something (Rust-in-Gecko is
 already being
 tracked on Bugzilla and we' probably should continue with that); but for
 now I don't see much of a reason to migrate, aside from avoiding having to
 migrate
 a larger Servo in the future.


Isn't that a good reason?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)

[Robert O'Callahan]

On Tue, Apr 28, 2015 at 4:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 For a layout engine, being able to attach an actual testcase to a bug
 report is _really_ useful once you get out of just build it mode and into
 fix all the bugs in this thing you built mode.  Github issues simply have
 no way to do this that I've been able to find.  You can put testcases on
 jsfiddle or other such services, but it's really hard to do minimal
 testcases that way because of all the things those services pull in, it's
 impossible to test some things (e.g. parser issues, quirks mode) because
 there's little control over the markup, and there are absolutely no
 guarantees your testcase will be around in 5 years when you want to see
 what that code change was trying to fix.

 This is really a problem I expect you'll want to solve at some point if
 you want to be able to get useful functionality bug reports and community
 QA.


Developers can commit testcases to a github repo and reference them with
github.io URLs, but that's no good for casual (e.g. web-developer level)
bug reporters. So, yes indeed.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 3/16 (Android nightlies; Q2 focus; testing strategies; usability; layout direction; Rust upgrade blocked)

[Robert O'Callahan]

 I have concerns about implementing full CSS algorithms in JS. People seem
to think that makes it fast by default.

It's more that what people are currently doing is crazy slow. Namely, to
implement a custom layout today, you typically have to
a) identify some DOM elements to measure (typically the children of a
container with custom layout)
b) synchronously lay out the entire document
c) take some measurements
d) jiggle some CSS properties around those elements
e) lay out the entire document again for rendering
And that's the *best* case. When you have multiple independent custom
layouts in the same page, steps b)-d) will probably repeat multiple times.
For some layouts (e.g. if you need both minimum and preferred intrinsic
widths) you may need to repeat b)-d) multiple times just for a single
layout.

It's easy to imagine how a custom layout API can beat that.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 3/16 (Android nightlies; Q2 focus; testing strategies; usability; layout direction; Rust upgrade blocked)

[Robert O'Callahan]

On Tue, Mar 17, 2015 at 3:12 PM, Patrick Walton pwal...@mozilla.com wrote:

 Sure, I agree that if you're doing custom layout languages (Cassowary,
 etc.) Houdini is a win—the comment was more directed toward use of Houdini
 to reimplement layouts that can already be described with CSS. For those
 use cases, without seeing any numbers, I'm unconvinced of the performance
 benefits.


If you reimplemented just the very simplest subset of, say, flexbox, maybe
it'd win over a fully general implementation, but I agree, that's not
compelling, and as far as I'm concerned, that's not a motivation to pursue
a custom layout API.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] WebGL canvas display

[Robert O'Callahan]

On Sun, Mar 15, 2015 at 6:38 AM, Patrick Walton pwal...@mozilla.com wrote:

 One issue is that we have to unconditionally layerize canvases for this,
 which violates the spec.


What do you mean, it violates the spec?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] UI Workers

[Robert O'Callahan]

On Tue, Feb 24, 2015 at 8:56 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp ga...@gavinsharp.com
 wrote:
  What does it mean to save your complex web app for later viewing?

 In gmail it would mean saving the set of emails that you are currently
 looking at.

 For facebook it would mean the news-feed content that's currently on
 the screen, or the event invitation details that you are currently
 looking at.

 That's what we would get if we serialized the current DOM+CSS+images
 to disk without any additional smarts. And all of these seem useful
 for users.


If we serialize the current DOM + CSS + images and remove the scripts, we
will present something to the user which is little more than a screenshot.
Users will immediately try to interact with it and discover that's broken.
That's a bad experience.

To present these in a non-broken way we must run page scripts. We should
not try to restrict the functionality of Web APIs for the sake of avoiding
this.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] UI Workers

[Robert O'Callahan]

On Tue, Feb 24, 2015 at 10:57 AM, Gordon Brander gbran...@mozilla.com
wrote:

 It’s funny: I have come to the opposite conclusion for the same reason.

 The Good: getting 60fps interactions and animations in web apps using a
 proven approach (UI and interaction thread).
 The Ideal: also automatically serializing those apps for offline use.


I agree with this.

Also, there is a way to get save for later viewing to work with complex
apps: serialize all the application state --- DOM, CSS, JS heap, workers,
etc --- and revive it later, possibly in a jail that blocks it from
accessing the network when revived, but possibly not. A lot of work to
implement, but not terribly difficult, and it would give you a great
experience, without restricting (explicitly or implicitly) what Web apps
can do.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] UI Workers

[Robert O'Callahan]

On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking jo...@sicking.cc wrote:

 I think this would fall over more often than not.

 Most developers will not write their code to be resilient in the face
 of being suspended for extended periods of time. Upon reopening they
 would likely display error dialogs, or updated version of whatever was
 saved.

 In fact, I would argue that it's directly harmful to keep even some of
 the app logic working. It could cause things like overwriting server
 state with whatever state was serialized into the saved copy.


You missed the part about the jail.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] UI Workers

[Robert O'Callahan]

On Fri, Feb 20, 2015 at 10:50 PM, Christopher Lord cl...@mozilla.com
wrote:

 I'd like to see #1 implemented first for two reasons; 1- I know this is
 easy to do given our platform, and I expect the same for other browser
 vendors, and 2- behaviour here is 100% predictable. There is nothing
 unexpected that can happen with this method and it's easy to employ. It
 doesn't require writing any JS, and developers are already used to
 optimising for the currently async-animatable CSS properties, so we can
 expect people not to do anything too silly with it.

 I'd like to see #3 implemented second, again for two reasons; 1- It's,
 again, reasonably easy to do. You can bypass a lot of machinery already,
 but making it explicit would make things easier and more obvious for
 people. I expect that part of this would also involve handling scrolling
 yourself too (we're on our way to removing the machinery to do synchronous
 scrolling, and it'd never respond the same way as async, so I think it'd be
 good to make it explicit). 2- There's a very clear use-case here. Not all
 web-apps are based around vertically scrolling a complex text layout, which
 is pretty much what the entire platform is built around. Games could get a
 nice boost here, as could some more unusual applications (e.g. scientific
 monitoring apps that mainly just want to draw charts very quickly (thinking
 specifically of Vernier LabQuest-style applications)).


It's easy to disable async scrolling. It's not so easy to make everything
fast enough (and isolated enough) for pages to do 60fps updates from their
main thread.

It sounds like you have a specific idea in mind for #3 that's more concrete
than what I wrote. I'd like to hear it :-).

I'd like to see #2 implemented the least, mainly because I think it's the
 most complex solution, from both the platform and the user side. It's
 worrying that behaviour is unpredictable - if you have a time budget, the
 same code on one device can deliver wildly different results on another,
 and I think this would just introduce inconsistent and unexplainable
 behaviour (from a user-perspective), and encourage developers to
 special-case particular devices and do awful user-agent string matching.
 This is a neat idea, but I just see it breaking more things than it solves,
 vs. the other two ideas. I'd probably change my mind given a compelling
 use-case, but I'm struggling to think of anything that couldn't be
 implemented with a combination of #1 and #3.


If we restrict all Web apps to effects that work on the very lowest-end
devices, people won't write Web apps. We need to facilitate graceful
degradation, but there must be degradation.

Also, I realise this is just a throw-away detail, but an 8ms budget would
 be pretty huge. I doubt we can get our compositing done on mobile if we
 halve our budget (we can barely get it done as it is).


When that's the case, we may need to add one frame of latency so we can
overlap compositing frame N with running the UIWorkers for frame N+1.

I do strongly think that #1 is the way to go immediately - people have been
 asking for this for ages (myself included), and it covers just about 90% of
 what you'd want to do, in a safe, easy-to-use and performant way.


Unfortunately I don't think it gets you near 90% of what people want to do.
For example, it doesn't let you express effects that depend on the
direction of scrolling, nor does it help you with any effects that aren't
related to scrolling.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] UI Workers

[Robert O'Callahan]

Last week in Sydney I spent a lot of time talking to Chrome devs about
different approaches for 60fps effects in Web pages. There are three
different kinds of approaches being discussed (so far):
1) Apple's animation-timeline proposal, which lets CSS animations use
scroll position as an input instead of time.
2) UIWorker: some kind of JS worker that receives callbacks during
composition; each callback can take inputs such as time and scroll
position(s) as inputs and can update certain CSS properties (e.g.
transforms, opacity) on elements that the compositor then uses.
3) Provide a way for pages to turn off async scrolling and make everything
fast enough (and isolated enough) for pages to do 60fps updates from their
main thread.

All of these approaches have problems. Approach #1 is much more limited in
its expressiveness than the alternatives. Approach #3 is more fragile and
less composable than the alternatives --- sharing your main thread with any
JS you don't control could cause jank. I like #2. It's strictly more
powerful than #1 without the downsides of #3.

Obvious question: how do we stop UIWorkers janking the compositor? We could
give them a time budget (say 8ms). If a worker blows its budget, we notify
it by sending it an event, we give up on it and composite anyway, and we
run it separately from the compositor for a while. This requires an API
design that lets UIWorkers still work, with some lag, when the compositor
is not blocking on them, but that seems doable.

Should UIWorkers have access to the full Worker API? It seems like there's
no reason not to give them that.

How should we explain the CSS effects of UIWorkers? A promising idea is to
extend the Web Animations API to allow adding a new kind of animation
effect to DOM elements --- a UIWorker-controlled effect. Essentially the
UIWorker would then be responsible for computing the output of the timing
function in each frame. The UIWorker could then animate *any* CSS property,
though most property updates would require a round trip through main thread
layout/rendering before they get rendered.

One good thing about UIWorkers is extensibility. We can imagine providing
touch input coordinates to UIWorkers to enable 60fps object dragging (with
arbitrary effects like resistance, snapping, etc). UIWorkers could render
to canvases: this would let you render VR with minimum latency, and let you
render to canvases used by CSS masking for 60fps dissolves and clipping
effects. If you really want to, you could go all Flipboard and render your
entire UI to a canvas in the compositor --- if you keep hitting your
deadlines.

I like the idea of doing #2 before either #1 or #3.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moz2D/Skia (meeting notes)

[Robert O'Callahan]

On Thu, Nov 13, 2014 at 2:03 AM, Nicolas Silva nical.si...@gmail.com
wrote:

 Well, depends on what you call a layer tree. Currently a layer tree is
 mostly a tree of intermediate surface that you render into, right? It's not
 a tool describe the content you want to rasterize (with the exception of
 color layers).


And ImageLayers...


 Our layer tree is about where you rasterize content rather than how
 (mostly). The gtk folks call the layer tree they are working on a
 scenegraph (but honestly I wouldn't call it that) so I suppose we need to
 be sure we talk about the same things. If a layer tree starts having things
 like shape layers, text layers, etc. then it becomes closer to what I call
 a scenegraph.


It's clear we could cleanly extend our current rendering approach with
layers directly rendering more kinds of content. I'm keen to understand
when and why this would be profitable. But I think that's offtopic for this
thread.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Moz2D/Skia (meeting notes)

[Robert O'Callahan]

https://github.com/servo/servo/wiki/Workweek-rasterization

We talked about writing our own rasterizer, which makes sense because web
 pages only render solid colored rectangles, image, and display text.


No. SVG, border-radius (rounded borders plus clipping to rounded shapes),
complex border styles, box-shadows and text-shadows are all commonly used,
and their performance matters. Plus you want to be able to rasterize these
precisely under arbitrary 2D affine transforms.

Firefox moved away from stateful APIs due to them being a bugfest,
 according to the notes from gfx.


Not really. See http://robert.ocallahan.org/2011/09/graphics-api-design.html
for an explanation.

Skia is closer to Canvas-style than to the Moz2D style.


Is it? Last time I looked I thought the other way around. E.g. you have
SkCanvas::drawArc taking an SkPaint object with all the current drawing
state, although admittedly SkPaint is heavier-weight than the Moz2D
parameter objects. If you subject Skia to the analysis of my above blog
post, I think it lands on the stateless side. The only stacked state in
SkCanvas is the transform, the clip and the filter, which is much less than
cairo (where almost every possible drawing parameter is part of the context
state). Even Moz2D stores transform and clip in the DrawTarget (which is
about the minimum you need for it to make sense to pass a DrawTarget to an
arbitrary function saying draw into this, which is essential).

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] JS engine (meeting notes)

[Robert O'Callahan]

https://github.com/servo/servo/wiki/Workweek-alt-js

I'm pleased with the Table discussion until mid 2015 outcome :-).

It might make sense at some point to have a super secure Servo build
where you plug in a JS interpreter and simple GC written in Rust, but I
can't see a viable general-purpose browser without a complex multitier JIT.

In the long term, we should be able to have that plus security by
translating SM into Rust and introducing some kind of TAL/PCC safety
checking of generated code, maybe with some offline theorem proving for
critical bits like GC. The state of the art in this area is advancing
reasonably quickly. But I can't see any rewrite the JS engine project
making sense for Servo even in the medium term unless the landscape changes
dramatically (e.g. massive quantities of new resources fall from the sky).

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] JS engine (meeting notes)

[Robert O'Callahan]

On Wed, Nov 12, 2014 at 11:42 AM, Cameron Zwarich zwar...@mozilla.com
wrote:

 On Nov 11, 2014, at 1:21 PM, Robert O'Callahan rob...@ocallahan.org
 wrote:
  https://github.com/servo/servo/wiki/Workweek-alt-js
 
  I'm pleased with the Table discussion until mid 2015 outcome :-).
 
  It might make sense at some point to have a super secure Servo build
  where you plug in a JS interpreter and simple GC written in Rust, but I
  can't see a viable general-purpose browser without a complex multitier
 JIT.

 Which use cases do you believe require a complex multitier JIT?


Games, visualizations, emulators, signal processing, document processing
(pdf.js), for starters.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moz2D/Skia (meeting notes)

[Robert O'Callahan]

On Wed, Nov 12, 2014 at 2:49 PM, Nicolas Silva nical.si...@gmail.com
wrote:

 If you guys ever have the resource to roll your own rasterizer, I would
 strongly suggest that you don't build an immediate mode api, and craft a
 more gpu-friendly scenegraph instead.
 To be honest I think that there is a lot of potential for improvement over
 what most browsers do today when it comes to rasterization. It's an
 interesting topic and I'd be happy to chat about it in Portland, and you
 guys should also talk with Bas and Cedric Bail if you haven't yet (Cedric
 doesn't work for Mozilla but he's got some interesting stuff to say about
 2d scenegraphs, and was interested in getting in touch with the servo team
 about this). I could go on about that stuff for hours so I'll propose the
 people who are interested in this gather and chat informally about it over
 a beer in Portland maybe, if only to exchange a bit about our latest issues
 we've had in gecko.


I'd like to talk about that too. I don't yet understand how gpu-friendly
scenegraph differs from layerize all the things! :-)

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] RFC: Making stacking contexts more first-class

[Robert O'Callahan]

On Mon, Nov 10, 2014 at 1:36 PM, Patrick Walton pcwal...@mozilla.com
wrote:

 On 11/9/14 4:31 PM, Josh Matthews wrote:

 I don't have any experience with these matters, but would this impact
 our ability to support the will-change CSS property? As I understand it,
 in Gecko the property basically means layerize this.


 `will-change` creates a new stacking context per the spec, so it shouldn't
 cause any problems.


To be precise, 'will-change: X' creates a new stacking context if and only
if 'X' is a property that induces a stacking context.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Invalidation test cases?

[Robert O'Callahan]

I still don't understand how your oveflow-based invalidation handles
reflows.

For example, suppose I have a regular document that's shorter than the
whole window and I append some text to the bottom. The height of the body
grows. Depending on the styles on the body, e.g. the value of
'border-radius' and certain 'background' values, you may or may not have to
repaint the entire window; in common cases you don't have to, and in Gecko
we found it very worthwhile to detect those cases. How would your
overflow-based invalidation handle this case?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Invalidation test cases?

[Robert O'Callahan]

On Wed, Oct 29, 2014 at 10:08 AM, Patrick Walton pcwal...@mozilla.com
wrote:

 On 10/28/14 1:46 PM, Robert O'Callahan wrote:

 For example, suppose I have a regular document that's shorter than the
 whole window and I append some text to the bottom. The height of the
 body grows. Depending on the styles on the body, e.g. the value of
 'border-radius' and certain 'background' values, you may or may not have
 to repaint the entire window; in common cases you don't have to, and in
 Gecko we found it very worthwhile to detect those cases. How would your
 overflow-based invalidation handle this case?


 It wouldn't handle that case well, as it would repaint the whole window.
 That is a good example :)


OK, but I still have the general question of how your overflow-based
invalidation handles reflows. The basic problem is style changes to element
A can result in geometry changes to element B where B is not a descendant
of A. For example suppose body contains two DIV children A and B and
something changes the height of A so B moves down. How does overflow-based
invalidation ensure B is repainted?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] The current scrolling model

[Robert O'Callahan]

On Wed, Oct 8, 2014 at 10:55 PM, Patrick Walton pcwal...@mozilla.com
wrote:

 On 10/8/14 10:51 PM, Robert O'Callahan wrote:

 You can get away with that for position:fixed, but I don't think you can
 get away with that for overflow:auto/scroll. We find in Gecko many real
 situations where scrolled content for a given scrollable container has
 to be split into multiple layers because content from the container is
 interspersed in z-order with content that's not scrolling.


 Samples of such content would be really interesting to take a look at and
 make sure we handle.

 In general our approach is functionally identical to WebKit's, so I
 suspect that whatever WebKit does we can just copy.


FirefoxOS Marketplace was one example. I don't have a simple example on
hand but I can make up one if you need one.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] The current scrolling model

[Robert O'Callahan]

On Mon, Oct 6, 2014 at 7:49 PM, Patrick Walton pcwal...@mozilla.com wrote:

 On 10/6/14 7:44 PM, Boris Zbarsky wrote:

 Just to check, what's the plan for doing overflow: sticky?  And does
 this model handle position:fixed things that end up both above and below
 pieces of a single position:static thing?


 I'd have to page `position:sticky` information back into my brain, but I
 can answer the second one, because it was needed for Acid2. When building
 display lists, we keep track of display items that were supposed to go on
 top of `position:fixed` and layerize them. This matches what WebKit does.
 Note that we don't implement pseudo-stacking contexts correctly (and
 neither does WebKit).


You can get away with that for position:fixed, but I don't think you can
get away with that for overflow:auto/scroll. We find in Gecko many real
situations where scrolled content for a given scrollable container has to
be split into multiple layers because content from the container is
interspersed in z-order with content that's not scrolling.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect

[Robert O'Callahan]

On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton pwal...@mozilla.com wrote:

 It might happen if layout is flushed from outside the script task; window
 resizing/device rotation being what immediately comes to mind, as today in
 Servo those events go straight from compositor to layout without hitting
 the script task at all. (As an alternative design, we could route such
 events through the script task; this would remove the necessity of the
 mutex but would block layout for such events if script is running, even if
 the script hasn't touched the DOM.)


Hmm. So given

var v = e.getBoundingClientRect();
// layout change is triggered by window resizing or whatever
var v2 = e.getBoundingClientRect();

what in Servo, prior to Clark's work, ensures v and v2 are the same?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes (Q3)

[Robert O'Callahan]

 jack: We also had questions about replacing Azure with a thinner layer for
 disk/memory reasons. We talked to Bas about our options. He has some ideas
 already about what he wants to build as a new browser-focused graphics API
 from scratch. But that would be a multi-year, multi-person project for
 Gecko. Servo, on the other hand, only draws four things (boxes, lines,
 images, and text). So we could start building the API with support for just
 those four things, and add more as we go along. That would let us get rid
 of Azure and replace it with something more direct that just generates
 OpenGL calls.


I don't know what's on Bas' mind, but it's not obvious to me how to design
a significantly better graphics API for browsers than Moz2D/Azure, which is
actually the result of going through just that process. If there is
something left on the table, let's evolve Moz2D towards it incrementally. I
don't want to add a 4th big-bang graphics API in Gecko.

I wonder why Moz2D memory usage is a problem for Servo when we're shipping
Gecko (with Moz2D) on a 128MB phone.

I think you need to look at the big picture rather than just what Servo
renders now. No point in stripping down an API just to add it all back
later.


- brson: we are not just a research project - we need other things -
like flash!
- jack: Shumway?


Shumway or nothing, surely.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] meeting notes (incremental layout)

[Robert O'Callahan]

- jack: can we avoid width recalc when changing vertical height?
pcwalton: that will break with vertical writing modes, among other
things. not sure it's a good optimization.


I'm not sure what jack had in mind exactly, but one very important
incremental layout case is appending content to a document (e.g. due to
incremental loading). That increases the heights of container elements, and
that had better not invalidate widths unnecessarily!

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes (Q3)

[Robert O'Callahan]

Sorry, I only just got to the workweek graphics meeting notes :-).

Servo will need to support 2D canvas, and it requires something like Moz2D.
So I think you're stuck with it or something like it.

I'll talk to Bas etc about fixing some of the resource management issues
your notes allude to in Moz2D. I think there are some things we can easily
improve there.


- martin: Now for fixed pos elements, it looks like overflow is
calculated as if the display port is at 0,0. Does that seem correct?
- pcwalton: For fixed position elements, they get a separate layer, so
you can use 0,0 and it should be fine... maybe check via mail to the
mailing list on what to do there so we can ask roc and/or bz? I don't know
what the right thing to do with position:fixed is off the top of my head.
- pcwalton: I think you're going to always want to render all
position:fixed things and never cull them out. So, how do we know to
descend into elements that contained fixed position things. Maybe we should
just have a list of them on the root, since that's their containing block
anyway and always go into the unconditionally. You want to descend into
containing block that intersect with the viewport. In this case, it's the
root, so you'll always want to.

 I'm not really sure what the question is. In Gecko the overflow area for
an element, er frame, is relative to the frame's own origin. position:fixed
content doesn't move relative to the viewport but we do compute its
overflow area based on the displayport bounds; this might be overkill but
it is sometimes necessary, e.g. during async pinch-zoom-out.

We mostly avoid culling involving position:fixed content, to make async
scrolling work, but we did find one case is important: where a
position:fixed element covers the entire viewport, we cull everything
behind it.

Another issue related to this is that getting 'opacity' and other container
effects to work properly with position:fixed and other out-of-flow content
is tricky. Consider e.g.
div style=opacity:0.5...div style=position:fixed.../div.../div
In Gecko we identify the out-of-flow content that is visible by traversing
special child lists for the abs-pos, fixed-pos etc children of a containing
block/viewport. But we can't paint them there and then because in this
example the fixed-pos content must be rendered as part of the in-flow
opacity:0.5 div (arbitrarily far away in the frame tree). So, after
identifying the OOF content we need to draw, we set flags to ensure our
frame-tree traversal descends down to the placeholder whether or not it's
on-screen, and build display items for the OOF content in the context of
the placeholder.

I hope some of this is helpful...

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] meeting notes (UTF8)

[Robert O'Callahan]

On Tue, Jul 8, 2014 at 2:51 PM, Cameron Zwarich zwar...@mozilla.com wrote:

 Are UTF8-backed (as opposed to Latin1-backed) JS strings with random
 access going to be a real possibility in SpiderMonkey? It’s obviously
 possible to make random access work with an appropriate indexing data
 structure, but popular JS benchmarks are pretty sensitive to string
 performance.


If Spidermonkey supported both UTF8 and UTF16, it could probably just
convert to UTF16 on the first charAt etc. I hope that would be good enough
for SS-crypto.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] meeting notes (COW DOM)

[Robert O'Callahan]

On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich zwar...@mozilla.com wrote:

 There is this blog post:

 https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/

 I’m friends with the author and have anecdotal confirmation that the
 improvements also occur on real web pages.


Good. I saw that, but wondered if anyone has more science.

Rob.
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Compositor Tree Redesign

[Robert O'Callahan]

On Tue, Jul 1, 2014 at 11:46 AM, Patrick Walton pcwal...@mozilla.com
wrote:

 On 6/30/14 4:44 PM, Robert O'Callahan wrote:

 BTW have you or anyone else working on Servo looked at
 TextureClient/TextureHost in Gecko? Getting buffer management interfaces
 correct across many platforms with multi-process and robustness in the
 face
 of crashes and platform quirks has proven to be very hard. I think we're
 in
 a good place now but we went down many blind alleys so there's some
 valuable lessons to be learned.


 By TextureClient/TextureHost I assume you mean cross-process texture
 sharing? If so, yes, we have been doing this from day one. (We have to,
 because we do painting on a separate thread.)


Yes. But if you haven't got robust support for D3D10 and Android gralloc
and Windows Media Foundation accelerated video decoding and all that sort
of thing, you probably don't have the design right unless you're cleverer
and luckier than the rest of us :-).

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] Compositor Tree Redesign

[Robert O'Callahan]

On Tue, Jul 1, 2014 at 1:21 PM, Patrick Walton pcwal...@mozilla.com wrote:

 On 6/30/14 6:20 PM, Robert O'Callahan wrote:

 Yes. But if you haven't got robust support for D3D10 and Android gralloc
 and Windows Media Foundation accelerated video decoding and all that
 sort of thing, you probably don't have the design right unless you're
 cleverer and luckier than the rest of us :-).


 It'd be good to discuss what the right design is then. I'm not wedded to
 our current design--it's pretty bare-bones at the moment anyhow (as things
 like synchronization are basically unhandled).


I don't know the details myself. Nicolas Silva would be a good person to
talk to. Maybe you should go through a design review with him.

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] Compositor Tree Redesign

[Robert O'Callahan]

On Tue, Jul 1, 2014 at 3:27 PM, Cameron Zwarich zwar...@mozilla.com wrote:

 How much of that changed the basic nature of the abstraction and how much
 of it was just difficult platform-specific implementation work?


Depends on the level of abstraction you're talking about, but we had to
restructure our IPC protocols a couple of times to account for specific
platform issues. The API between layers and layout did not change, but a
lot of the layers implementation did.

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] 3/24 meeting notes (greetings; android; acid2; rust upgrade)

[Robert O'Callahan]

 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.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] 3/24 meeting notes (greetings; android; acid2; rust upgrade)

[Robert O'Callahan]

On Tue, Mar 25, 2014 at 9:41 AM, Patrick Walton pcwal...@mozilla.comwrote:

 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.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] JST guide

[Robert O'Callahan]

On Wed, Mar 5, 2014 at 11:33 AM, Josh Matthews j...@joshmatthews.netwrote:

 I know that some contributors have expressed confusion about the new JST
 types that are all over the DOM. I've started a guide to try and clear up
 how to use them; please feel free to suggest further topics or make edits
 yourself: https://github.com/mozilla/servo/wiki/JS-smart-pointers



let base: JSNode = NodeCast::from(element);if base.get().type_id()
== ElementNodeTypeId(HTMLTitleElementTypeId) {
  let derived: JSHTMLTitleElement = HTMLTitleElementCast::to(element);}

Can this not be simplified to something like
  let derived = HTMLTitleElement::checkedCast(element);
returning an OptionJSHTMLTitleElement? Less verbose and less
error-prone that the instanceof/downcast pattern.

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] JST guide

[Robert O'Callahan]

On Wed, Mar 5, 2014 at 12:55 PM, Josh Matthews j...@joshmatthews.netwrote:

 It can be, but there are cases when that would be wasted effort. I'm open
 either way.


In XPCOM terms, the vast majority of QueryInterface calls do more with the
returned pointer than a null check. So I think you'll find it well
worthwhile to provide the maximally-convenient checked downcast.

Even when you just need instanceof, can it be shortened to
  if (HTMLTitleElement::hasInstance(element))
?

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] Roadmap Q2 goal : Pass Acid3

[Robert O'Callahan]

On Wed, Feb 26, 2014 at 7:02 AM, Patrick Walton pcwal...@mozilla.comwrote:

 So I agree that we must not make architectural decisions that make it
 difficult to implement Web features. But I do think that Web compat is
 useful, because it helps us to identify the parallel hazards and know where
 we stand in terms of the Web of today, which helps us answer the big
 questions that Servo set out to answer.


That's a good point, but Acid3, and to a lesser extent Acid2, are about
testing edge cases and the presence of obscure features. I don't think they
tell you anything significant about parallelism in the mass of pages on the
Web. No single page can, but Acid3 is probably even worse than picking a
page at random. You'd be much better off picking, say, a Wikipedia page
(which I know you've done!) or the HTML5 single-page spec.

Otherwise, we don't know whether the parallel gains that we are getting
 will scale up to real-world usage, or whether we're only getting them
 because we don't implement the difficult features.


That's a good point too, but the problem is that key parts of the Web like
GMail, Youtube, Facebook etc require so much work for full support that I
don't think we draw broad conclusions until very far in the future, when it
will be far too difficult to make architectural changes. If you must
discover those conclusions earlier then we should probably piggyback some
analysis on an existing browser engine instead of doing it in Servo.

The good news is that I think CSS layout is by far the largest piece of the
Web where we have implicit parallelism that is subject to unpredictable
hazards. Other big chunks of work, like almost all DOM APIs, are either
obviously not parallelizable or obviously parallelizable.

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

[dev-servo] Display list stuff

[Robert O'Callahan]

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.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 2013-11-04: mac builder failure, priorities (C++, layout, parallelism, rustpkg, embedding, graphics)

[Robert O'Callahan]

I had a discussion with pcwalton and kmc yesterday about string interning.
The concurrent cuckoo hash table is cool but maybe not the right fit for
the browser workload for a couple of reasons:
a) interning lookups are mostly not on the hottest paths. They will occur
during parsing, and that can mostly happen off the main thread. Parsing
selectors for querySelectorAll etc would happen on the main thread (or at
least synchronously with it), but we cache parsed selectors in Gecko anyway
(as of recently). Also, we have the option of wrapping a thread-local cache
around the global intern table.
b) it's important to efficiently resize the table and shrink it by removing
unused atoms. That may not be easy to add to the concurrent cuckoo table.

Regarding new layout features, I think it's important to tackle some
architectural issues before adding more features:
-- Bidi and vertical text
-- Fragmentation (page/column/overflow:fragments breaking)
The former introduces abstractions that will be easier to introduce now
than any time in the future, since all your layout features will build on
them. The latter is a big architectural thing that will also be easier to
introduce now than in the future, and also may impact your design in
fundamental ways.

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] 9/23 meeting - leaks, crashes, reflow performance, demos

[Robert O'Callahan]

nsBlockReflow, and most layout code, is indeed inefficient. Some amount of
that is because we support a lot of features and we've fixed a lot of bugs.
Fixing bugs tends to add code, and even if you try to keep things off
commonly taken paths, even not-taken conditionals add up.

I guess I'm saying that you really want to be quite a bit faster than Gecko
because over time you'll gradually slow down as you are able to handle more
of the Web. Although, since we have better specs and better understanding
of their implementation than we did as Gecko evolved, there's some hope
Servo will end up less crufty.

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

[Robert O'Callahan]

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

[Robert O'Callahan]

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] Unanswered questions from a QA about Servo

[Robert O'Callahan]

On Fri, Jul 12, 2013 at 11:33 AM, Patrick Walton pwal...@mozilla.comwrote:


 * Do we have data showing how many security bugs we could be avoiding in
 Servo in comparison to Gecko? Is the security benefit truly as valuable
 if expected performance benefits don't pan out?


 We've been talking to some members of the security team (Jesse, Brian). In
 general the main class of security vulnerabilities that Rust offers a layer
 of defense against is memory safety problems in layout, rendering, and
 compositing code. Use-after-free is the big one here, but there are others.
 I'm not in the sg so I can't run the numbers myself, but I am told this
 constitutes a large class of security vulnerabilities.


A quick scan suggests that all 34 sec-critical bugs filed against Web Audio
so far are either buffer overflows (array-access-out-of-bounds, basically)
or use-after-free. In many cases the underlying bug is something quite
different, sometimes integer overflows.

Rust and Servo can potentially be pushed further to get additional
interesting security properties, but that requires more research.

Having said that, if we can't get superior performance, it won't fly no
matter what security we get.

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] Unanswered questions from a QA about Servo

[Robert O'Callahan]

On Fri, Jul 12, 2013 at 6:00 PM, Patrick Walton pwal...@mozilla.com wrote:

 In general the overhead for writes and borrows will probably be only a
 couple of instructions over a dereference operation. Reads should be
 unbarriered, although I think we need a little more design to make that
 happen in the current language.


That sounds good, thanks.

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] Unanswered questions from a QA about Servo

[Robert O'Callahan]

On Fri, Jul 12, 2013 at 5:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote:

 A quick scan suggests that all 34 sec-critical bugs filed against Web
 Audio so far are either buffer overflows (array-access-out-of-bounds,
 basically) or use-after-free. In many cases the underlying bug is something
 quite different, sometimes integer overflows.


There are 4 sec-high bugs --- DOS with a null-pointer-deref, and a few bugs
reading uninitialized memory. The latter would be prevented by Rust, and
the former would be mitigated to the extent Servo uses the fine-grained
isolation Rust offers.

There are no sec-low bugs.

Web Audio is an example of a feature which has very little security impact
of its own. Its security impact is entirely due to bugs where violation of
language rules can trigger arbitrary behavior. Rust prevents such bugs. A
lot of Web features are in this category.

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] More planning

[Robert O'Callahan]

On Thu, Feb 14, 2013 at 7:19 PM, Luke Wagner l...@mozilla.com wrote:

  Eventually I can imagine writing the JIT in Rust and using some kind of
 certified
  compilation to guard against compiler bugs.

 I haven't really followed this topic; do you really think this would be a
 feasible approach to a production JS engine?  I appreciate that we'd only
 have to certify that the jit code was safe, not correct, but that still
 doesn't seem significantly easier given the complexity of jit techniques
 required to achieve competitive JS performance.


I haven't kept up with the state of the art, but I guess it's feasible with
enough effort, using a combination of static theorem proving and online
verification. For a fully sound system the hardest part might be proving
the correctness of GC. It's fair to question whether this is really
something we should depend on. On one hand, it's research, on the other
hand, technology in this area is improving pretty rapidly. IIRC for
Singularity/Midori Microsoft has verified type safety for the entire stack
down to the machine code (that's a static compiler, not a JIT, and C#, not
JS ... but C# is hard in its own way).

I'm more confident that someone will eventually be able to do this than
that we'd be able to do it in any given timeframe.

 For now, just get it right :-).

 It seems like a scary-large proportion of security sensitive bugs come out
 of the JS engine (and it's not because we don't care :).


I thought layout was that scary-large portion :-).


  Sure, the JS JIT will have to be part of the TCB for now.

 If the certified-compilation scheme doesn't work out (this eventuality
 seeming rather likely IMHO), it seems like making this TCB assumption early
 on would lead us to make some bad architectural decisions that would be
 difficult to fix later (a story we know all to well :).


True, but there is also a danger that fear of being architecturally
boxed-in causes us to do something over-elaborate :-).

I have the impression that the non-JS part of the Web platform grows at a
much faster rate than the JS part, and lots of the JS part doesn't even
need to be in the TCB. So I hope the proportion of sec-sensitive JS bugs
goes down. Maybe.

I wonder whether it would make sense to provide process separation and
sandboxing in the Rust runtime. Is there any reason why we couldn't
identify clusters of Rust tasks and wrap them up into sandboxed processes,
verifying message integrity at process boundaries? (Choice of process
boundaries would be made manually, I'm not talking about crazy automation.)
If that's doable transparently (in semantics, if not performance),
sandboxed processes at whatever granularity desired could be retrofitted as
needed without changing Servo code.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

[Robert O'Callahan]

On Sun, Oct 21, 2012 at 6:50 PM, Patrick Walton pwal...@mozilla.com wrote:

  It seems to me that Google Chrome would have the same problems here,
 since it runs different origins in different processes.


AFAIK, in Chrome, if two JS documents can reference each other's heaps, it
puts them in the same process, even if they're different origins.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others? [Matthew 5:43-47]
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

[Robert O'Callahan]

On Sat, Oct 20, 2012 at 9:55 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 Do we have a plan for adoptNode?  If we're allocating nodes out of the JS
 heap, presumably we'll need to brain-transplant the JSObject and then copy
 over the implementation into the new compartment... and make sure we update
 any pointers to the implementation, right?


Couldn't we replace the original with a proxy that forwards to the new
object? It would get a bit complex if the node is adopted many times, but
seems like it ought to work.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others? [Matthew 5:43-47]
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo