Re: [dev-servo] Omar Mozilla Intern Introduction

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

Re: [dev-servo] Omar Mozilla Intern Introduction

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

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

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

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

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

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

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 a

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

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 boun

Re: [dev-servo] Blink's new layout proposal

It's a little surprising to me that they don't mention incremental relayout at all. Especially because that has significant interactions with their immutability goal, which is the part of their document I'm pretty skeptical about. OTOH their approach to fragmentation sounds like a good direction.

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

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

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

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 goe

[dev-servo] MathML

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

Re: [dev-servo] Chaos mode!

Thanks Matt! A couple of things: -- if this is helpful, I'd like to hear about the bugs that it helped with. -- if you have bugs that you can't reproduce with rr chaos mode, but you figure out some other way, I'd really like to hear about those. I want to study such bugs to figure out how to impr

Re: [dev-servo] Student Project

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 com

Re: [dev-servo] IndexDB project

On Tue, Dec 15, 2015 at 12:33 AM, Paul Rouget wrote: > On Tue, Dec 15, 2015 at 5:27 AM, Manish Goregaokar > wrote: > > On Tue, Dec 15, 2015 at 9:39 AM, Robert O'Callahan > > > wrote: > > > >> > >> FWIW I think this project falls into the cat

Re: [dev-servo] IndexDB project

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 Gec

Re: [dev-servo] Testing against regressions in RestyleDamage

On Sat, Dec 5, 2015 at 3:21 AM, Martin Robinson wrote: > Every node and flow tree element (Flows and Fragments) have a bitflag > which tracks the type of damage caused by restyling and DOM > manipulation. This flag is used during incremental layout to only repair > parts of the tree that actually

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

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 sty

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

On Thu, Nov 5, 2015 at 12:44 AM, James Graham 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 &g

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

On Thu, Nov 5, 2015 at 12:17 AM, James Graham 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 >>> shimm

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

On Wed, Nov 4, 2015 at 11:50 PM, James Graham wrote: > On 04/11/15 10:24, Robert O'Callahan wrote: > >> On Wed, Nov 4, 2015 at 5:14 PM, James Graham >> wrote: >> >> On 03/11/15 22:08, Robert O'Callahan wrote: >>> >>> Why not cre

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

On Wed, Nov 4, 2015 at 5:14 PM, James Graham 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(),

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

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 showstopp

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

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

[dev-servo] reftests vs testing display lists

Many Webkit layout tests use DRT (DumpRenderTree), which dumps the layout object tree and compares against reference text files. These became difficult to maintain as the layout engine evolved and such tests are not portable to any other engine. Testing display list dumps sounds like it would have

Re: [dev-servo] WebRender

On Tue, Sep 29, 2015 at 4:36 PM, Patrick Walton wrote: > Well, the idea here is to test the case in which the object isn't > layerized for some reason--say, the object was moving by animating > "margin-left" in JavaScript and it had complex Z-ordering constraints that > caused whatever layerizati

Re: [dev-servo] WebRender

On Tue, Sep 29, 2015 at 3:55 PM, Glenn Watson wrote: > It's a fairly simple off canvas menu - it is full height (1024px in this > test), and expands from off-screen to 600px wide. It has a linear gradient > for the background, and a small amount of text on it. > > I was also surprised the existin

[dev-servo] WebRender

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 uresy

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

On Mon, Aug 10, 2015 at 1:52 PM, Josh Matthews 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

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

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

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

On Fri, Jul 24, 2015 at 10:26 AM, Josh Matthews 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 ure

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

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 u

Re: [dev-servo] Multiprocess safety

On Fri, Jun 19, 2015 at 7:10 PM, Patrick Walton 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

Re: [dev-servo] Multiprocess safety

On Fri, Jun 19, 2015 at 12:45 PM, Patrick Walton 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 oaonoyoo

[dev-servo] layerization and stacking contexts

FYI, the Blink team is deep into a project ("slimming paint") that will fix the bugs they inherited from Webkit that make layerized elements higher in z-order than they should be. Gecko never had those bugs, of course. I'm not sure of the state of IE, and I don't know of any plans to fix those bugs

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

On Tue, Apr 28, 2015 at 7:32 PM, Manish Goregaokar 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

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

On Tue, Apr 28, 2015 at 4:52 PM, Boris Zbarsky 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

Re: [dev-servo] Making reflowing animations as fast as compositable animations

On Sun, Mar 22, 2015 at 8:03 AM, Patrick Walton wrote: > A hypothetical requestAsyncAnimationFrame() API whose callback had no > general access to the DOM and window object (though you could, for example, > pass specific DOM objects in to mutate their styles) would solve this > issue. Google's ol

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

On Tue, Mar 17, 2015 at 3:12 PM, Patrick Walton 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, with

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

> 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 th

Re: [dev-servo] WebGL canvas display

On Sun, Mar 15, 2015 at 6:41 PM, Patrick Walton wrote: > Actually, come to think of it, we could probably eliminate that > performance hazard by switching the stacking-context-to-layer mapping from > 1:1 to 1:N. Since finalized display lists are flat lists of drawing > commands, this shouldn't be

Re: [dev-servo] WebGL canvas display

On Sun, Mar 15, 2015 at 6:10 PM, Patrick Walton wrote: > We can only layerize stacking contexts, since we have no FrameLayerBuilder. > So we have to promote canvases to stacking contexts if we want to layerize > them. WebKit does the same thing. > You should fix that. Blink is :-) Rob -- oIo o

Re: [dev-servo] WebGL canvas display

On Sun, Mar 15, 2015 at 6:38 AM, Patrick Walton 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 ob

Re: [dev-servo] UI Workers

I've posted a followup of sorts to public-houdini: https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0020.html There have been no replies, so I suspect I've said something terribly incomprehensible and/or wrong :-). Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaon

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking 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 upda

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 10:57 AM, Gordon Brander 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

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 7:36 AM, Jonas Sicking wrote: > On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan > wrote: > > Your use-cases already fail today because many Web pages use scroll event > > handlers and JS custom layouts. UIWorkers won't make the problem a

Re: [dev-servo] UI Workers

On Tue, Feb 24, 2015 at 8:56 AM, Jonas Sicking wrote: > On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp > wrote: > > What does it mean to "save your 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

Re: [dev-servo] UI Workers

On Fri, Feb 20, 2015 at 10:50 PM, Christopher Lord 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

Re: [dev-servo] UI Workers

On Fri, Feb 20, 2015 at 9:11 PM, Jonas Sicking wrote: > On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan > wrote: > > Should UIWorkers have access to the full Worker API? It seems like > there's > > no reason not to give them that. > > There's two

Re: [dev-servo] UI Workers

On Fri, Feb 20, 2015 at 4:02 PM, James Long wrote: Personally I think what we *really* need to be working on is making all of the DOM APIs asynchronous. That's what Servo needs anyway. That's a step in the right direction for #3, and we can see much more we can get out of the main

[dev-servo] UI Workers

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 inste

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

On Thu, Nov 13, 2014 at 2:03 AM, Nicolas Silva 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).

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

On Wed, Nov 12, 2014 at 2:49 PM, Nicolas Silva 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 potentia

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

On Wed, Nov 12, 2014 at 11:42 AM, Cameron Zwarich wrote: > On Nov 11, 2014, at 1:21 PM, Robert O'Callahan > wrote: > > https://github.com/servo/servo/wiki/Workweek-alt-js > > > > I'm pleased with the "Table discussion until mid 2015" outcome :-).

[dev-servo] JS engine (meeting notes)

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

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

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 st

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

On Mon, Nov 10, 2014 at 1:36 PM, Patrick Walton 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 "layeri

Re: [dev-servo] Invalidation test cases?

On Wed, Oct 29, 2014 at 10:08 AM, Patrick Walton 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 >> gro

Re: [dev-servo] Invalidation test cases?

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 grows. Depending on the styles on the , e.g. the value of 'border-radius' and

Re: [dev-servo] The current scrolling model

On Wed, Oct 8, 2014 at 10:55 PM, Patrick Walton 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 >> sit

Re: [dev-servo] The current scrolling model

On Mon, Oct 6, 2014 at 7:49 PM, Patrick Walton 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? >>

Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing

On Tue, Oct 7, 2014 at 6:57 AM, Henri Sivonen wrote: > On Mon, Oct 6, 2014 at 8:27 PM, Cameron Zwarich > wrote: > >> So you’re suggesting Servo could get away with UTF-8 in the DOM? I > hadn’t considered it. I remove my proposal at the start of this thread, I’d > like us to try this instead. > >

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

On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton 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 t

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

On Fri, Aug 29, 2014 at 12:56 PM, Cameron Zwarich wrote: > Is it strictly enforced that the script task never sees inconsistent views > of layout? This came up in the other thread about threading, but what > prevents this incorrect scenario? > > 1) The script task takes the mutex to access one pr

Re: [dev-servo] Servo's use of threads

On Wed, Aug 27, 2014 at 11:25 AM, Cameron Zwarich wrote: > 1) Script task completes execution. > > 2) Some external stimulus triggers layout. > > 3) Flow tree construction takes the DOM lock, creates the flow tree, and > releases it. > > 4) Before layout actually begins, the script task begins ex

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

On Thu, Jul 10, 2014 at 9:56 AM, Patrick Walton wrote: > On 7/9/14 2:48 PM, Robert O'Callahan wrote: > >> If you think so, then I think we *should* be considering GC+CC for Servo. >> >> Crazy idea: could it even make sense for JS GC to use a traced nursery >>

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

On Thu, Jul 10, 2014 at 9:53 AM, Patrick Walton wrote: > On 7/8/14 1:23 PM, smaug wrote: > >> In general issues with GC handling are security bugs, but in CC they >> lead to leaks. >> > > This is not the case in Servo, though; we should be foolproof for both. > I'm definitely not willing to compr

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

On Wed, Jul 9, 2014 at 8:23 AM, smaug wrote: > In general issues with GC handling are security bugs, but in CC they lead > to leaks. > > I could note that max median CC times have been lower than max GC slice > times at least since early 2012. > CC needs to deal with possible garbage only, GC ten

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

On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich 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 w

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

On Tue, Jul 8, 2014 at 2:51 PM, Cameron Zwarich 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

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

On Tue, Jul 8, 2014 at 2:56 PM, Patrick Walton wrote: > Yeah, I shouldn't have mentioned safety there, since the fundamental > problem is the same whether or not you use CC or GC. You still have to > teach the JS engine or the CC about the object graph. > > We use compiler support for this in Rus

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

On Tue, Jul 8, 2014 at 2:48 PM, Cameron Zwarich wrote: > We would also want to ensure that Harfbuzz and Moz2D aren’t somehow > creating duplicate copies of font data on all platforms. > They don't on Gecko, we've worked on that. I agree that image data and tile buffers are going to be very imp

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

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 Moz

[dev-servo] meeting notes (COW DOM)

> > >- pcwalton: if we can offer things like getComputedStyleAsync, that >could be a bigger win for authors using them. >- jack: that doesn't help us now. > > Apart from what jack said, getComputedStyleAsync might be unusable for a lot of Web authors. Personally I agree with the conclu

[dev-servo] meeting notes (UTF8)

I'm excited about pushing UTF8 as far as possible! One thing not mentioned in the notes is that Spidermonkey is adding Latin-1 string support, so hopefully it will be pretty easy to avoid converting ASCII-only strings at WebIDL boundaries. It would certainly be ideal if Spidermonkey eventually sup

[dev-servo] meeting notes (incremental layout)

> > >- 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 appendi

[dev-servo] Meeting notes (Q3)

> > 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 proje

Re: [dev-servo] Compositor Tree Redesign

On Tue, Jul 1, 2014 at 3:27 PM, Cameron Zwarich 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 proto

Re: [dev-servo] Compositor Tree Redesign

On Tue, Jul 1, 2014 at 1:21 PM, Patrick Walton 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

Re: [dev-servo] Compositor Tree Redesign

On Tue, Jul 1, 2014 at 11:46 AM, Patrick Walton 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 pla

Re: [dev-servo] Compositor Tree Redesign

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 bu

Re: [dev-servo] Table-less string interning

It seems like it would be a good idea to instrument Gecko to gather a trace of intern operations from regular Web browsing that you can run against test programs. Making the interned atom for <= 8-char or 4-char ASCII strings be the string itself is a really interesting idea. Another idea I like

Re: [dev-servo] character encoding in the HTML parser

On Wed, Apr 2, 2014 at 10:45 AM, Luke Wagner wrote: > Nick just brought up the topic of adding a second compact string > representation to the JS engine (motivated by string memory use). One > question was whether to use ASCII (which V8 does, iirc) or UTF8. Several > DOM people have pointed out

Re: [dev-servo] character encoding in the HTML parser

On Tue, Apr 1, 2014 at 3:18 PM, Boris Zbarsky wrote: > On 4/1/14 3:07 PM, Keegan McAllister wrote: > >> Who should I talk to about JS string representation changes? >> > > Eddy Bruel. ejpbruel at mozilla dot com. If we could get the JS engine to use evil-UTF8 with some hack to handle charAt an

Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)

On Tue, Mar 25, 2014 at 9:41 AM, Patrick Walton wrote: > On 3/24/14 1:40 PM, Robert O'Callahan wrote: > >> >>> We have multiple layers support. I reworked because it was bogus, but >>> it's >>> a hard problem with iframes in multiple thread

Re: [dev-servo] 3/24 meeting notes (greetings; android; acid2; rust upgrade)

> > We have multiple layers support. I reworked because it was bogus, but it's > a hard problem with iframes in multiple threads Would it be helpful to explain how multiprocess layer trees work in Gecko? Very different than it was before because they're doing it without false > DOM nodes - all f

Re: [dev-servo] Dealing with fragmentation/pagination

On Tue, Mar 11, 2014 at 3:25 PM, Andrei Bucur wrote: > Could you give me an example of that situation? It¹s not very clear to me > what case you are talking about so I can only speculate. To elaborate a > bit what I said in my previous email: > 1. Two fragments overlap during the layout (e.g. neg

Re: [dev-servo] Dealing with fragmentation/pagination

On Tue, Mar 11, 2014 at 1:53 AM, wrote: > We currently have two methods of painting content flows. The multi-column > flows are painted using a special fragment structure at a layer level. For > regions we use a different mechanism that's based on clipping information > collected during layout. W

Re: [dev-servo] JS guide

On Wed, Mar 5, 2014 at 12:55 PM, Josh Matthews wrote: > 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

Re: [dev-servo] JS guide

On Wed, Mar 5, 2014 at 11:33 AM, Josh Matthews wrote: > I know that some contributors have expressed confusion about the new JS > 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:

Re: [dev-servo] Roadmap Q2 goal : Pass Acid3

On Wed, Feb 26, 2014 at 7:02 AM, Patrick Walton wrote: > 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

Re: [dev-servo] Roadmap Q2 goal : Pass Acid3

I don't think we should be setting these kinds of goals for Servo in the short term. Passing Acid-style tests or meeting site-compatibility criteria require doing a lot of work that is not particularly risky and does not have much architectural impact on the engine ... but there's a lot of work to

Re: [dev-servo] Dealing with fragmentation/pagination

On Sat, Feb 22, 2014 at 8:48 AM, Patrick Walton wrote: > You mentioned that we should be thinking about fragmentation and > pagination now. I heard from Seth that Gecko uses multiple frames for > fragmentation, that this adds a lot of complexity, and that you potentially > wanted to try using a si

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On Thu, Feb 20, 2014 at 5:55 PM, wrote: > roc wrote: > > > > One of the things I would like us to consider (in both Gecko and > > > Servo) is to stop using any available platform fonts by default. > > > We should keep a list of normal system fonts and only use those. > > > If a site wishes to use

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

On Fri, Feb 14, 2014 at 1:43 PM, Boris Zbarsky wrote: > On 2/13/14 5:56 PM, Robert O'Callahan wrote: > >> 2) Fragmentation. With something like overflow:fragments, absolute >> positioning can affect the number of fragments you generate, which can >> affect the

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

On Fri, Feb 14, 2014 at 12:53 PM, Patrick Walton wrote: > For the first concern, I realized that pages like that are going to be > sequential no matter what we do, of course, because of the way parallel > tree traversals work. So never mind there. The O(n^2) update of overflow > areas still concer

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

On Fri, Feb 14, 2014 at 11:42 AM, Boris Zbarsky wrote: > On 2/13/14 4:48 PM, Patrick Walton wrote: > >> The pull request #1681 takes approach #2. It deals with the parallel >> hazard by deferring height computation of absolutely positioned blocks >> until display list construction time (which is

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On Thu, Feb 13, 2014 at 9:14 AM, Patrick Walton wrote: > On 2/12/14 12:06 PM, Robert O'Callahan wrote: > >> For Servo, I would pull the font.name <http://font.name> prefs from >> >> all.js to get a fixed list of per-language font names to use for >> fall

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On Thu, Feb 13, 2014 at 5:59 AM, Benjamin Smedberg wrote: > One of the things I would like us to consider (in both Gecko and Servo) is > to stop using any available platform fonts by default. We should keep a > list of normal system fonts and only use those. If a site wishes to use > other fonts,

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On Wed, Feb 12, 2014 at 5:00 PM, Patrick Walton wrote: > On 2/10/14 12:41 PM, Robert O'Callahan wrote: > >> What exactly do you mean by "font collection loading"? If you ask the >> right >> questions I can explain how it works in Gecko :-). >> > >

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

> > We have no way of benchmarking wikipedia or any real site because of font > collection loading, which we do during style recalc. I don't know where the > other browsers do it, but because we do it during style recalc, it kills > our numbers. What exactly do you mean by "font collection loadin

  1   2   >