Re: [dev-servo] UI Workers

[Robert O'Callahan]

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 use-cases that I think argues against that.
>
> First off I'd like to enable saving a webpage for later viewing. Right
> now the best we can do is to save a pdf which means that all
> scrollable areas are lost.
>
> Saving a full page with all scripts is rarely going to work result in
> the user seeing the page they did when saving the page.
>
> What I'd like to be able to do is serialize the DOM, strip all script,
> save all linked stylesheets, images and media and change the
> references to them to use the correct relative URLs.
>
> However this would require also saving the UIWorker and enabling it to
> run in a reliable way. Otherwise the saved page won't have a working
> layout.

Second, when printing, I'd like to enable the user to change page
> layout and margins and have that reflow the page and generate a
> correct layout. This means that we need to enable the UIWorker to work
> on the cloned document in a reliable way.
>
I think both these usecases would work much better if we ensured that
> the UIWorker couldn't "interact with the outside world".
>

Your use-cases already fail today because many Web pages use scroll event
handlers and JS custom layouts. UIWorkers won't make the problem any worse.

Furthermore, I think facilitating expressive performant mobile Web apps is
much more important than those use-cases, and preventing UIWorkers from
interacting with the outside world (including, I assume, the application
main thread) would severely limit their usefulness.

Personally I think it's futile to try to save a complex app "for later
viewing" and expect anything useful to happen unless the whole app is
captured and able to operate offline.

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 
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] PRs are now gated on building on gonk

[Lars Bergstrom]

In addition to testing on Linux and OSX plus building from Linux targeting 
Android, we will now gate Servo PRs on also building on Linux targeting Gonk.

Thanks to the initial work by Michael Wu and some great follow-up work by 
Manish, we now have pretty well-automated builds of Servo targeting Gonk 
(“b2s”), though (like Android) we still have some Rust/Cargo bugs with OSX 
cross compilation, so it’s Linux-only for now. Instructions on how to build and 
run it are at:
https://github.com/servo/servo/blob/master/ports/gonk/README.md 


Pending some quick administrative checks, we will try to make a “mach 
boostrap-b2g” command similar to our other bootstrap commands so that people 
don’t have to have a flame device attached and then enlist in + build all of 
b2g.

Thanks to Michael and Manish for pulling together this support, and hopefully 
now that we’ll keep it building others will be able to more easily experiment 
with this target!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo