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
triggered by a game controller (with all the hardware
latencies combined) can take longer than a transatlantic network roundtrip.
Even if the introduced latency is consistent, it could make UI Workers less
suitable for gaming.
Kind regards,
Srđan Prodanović
http://spamoji.com
On Mon, Feb 23, 2015 at 4:26 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
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
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).
Funny, the first advanced use-case that came to my mind for UI workers was
re-ordering icons on the gaia homescreen :)
There's a bit of everything: we
What does it mean to save your complex web app for later viewing?
I don't think there's a lot of overlap between sites that would use
the functionality roc is proposing, and sites that make sense to save
for later viewing.
Gavin
On Mon, Feb 23, 2015 at 10:36 AM, Jonas Sicking jo...@sicking.cc
On Thursday, 19 February 2015 18:27:48 UTC-8, Robert O'Callahan wrote:
Last week in Sydney I spent a lot of time talking to Chrome devs about
different approaches for 60fps effects in Web pages.
One complaint I see that is pretty common: image decoding on the main thread in
WebKit. I don't
On Monday, 23 February 2015 10:37:09 UTC-8, Jonas Sicking wrote:
The lack of ability to save for later viewing is a big problem on mobile.
The fact that native is so much better at retaining content to make it
available later when the user is offline is one of the big reasons
that the web
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
On Fri, Feb 20, 2015 at 9:11 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan rob...@ocallahan.org
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
On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan rob...@ocallahan.org 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
On Thu, Feb 19, 2015 at 7:11 PM, James Long longs...@gmail.com wrote:
Note however that people in the native app world believe that it's
very important that whatever applies the animations is run on the same
thread that handles input. Otherwise it's very easy for animations to
get out-of-sync.
On Fri, Feb 20, 2015 at 3:27 AM, Robert O'Callahan rob...@ocallahan.org wrote:
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
It's great to see this being discussed! Personally, I'd like to see all
three of these, and I think they have quite particular use-cases. #2 is my
least favourite, however, and I'll discuss this below.
I'd like to see #1 implemented first for two reasons; 1- I know this is
easy to do given our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2015 09:12 PM, Jonas Sicking wrote:
On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg
jwajsb...@mozilla.com wrote:
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
On Fri, Feb 20, 2015 at 4:02 PM, James Long
longs...@gmail.com wrote:
On Fri, Feb 20, 2015 at 3:20 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 19, 2015 at 7:11 PM, James Long longs...@gmail.com wrote:
Note however that people in the native app world believe that it's
very important that whatever applies the animations is run on the same
thread that
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com 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
On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg jwajsb...@mozilla.com wrote:
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com wrote:
Personally I think what we *really* need to be working on is making
all of the DOM APIs
On Thu, Feb 19, 2015 at 10:25 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com 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.
I'm not heavily involved in platform work, so take my input as a
somewhat naïve outsider. I've been tracking this kind of stuff very
closely, especially after I got to play with react native.
The place where this is most important is mobile, and I don't think #2
is going to cut it. It's not just
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
Sorry, I may have missed the last part of your email where you say
that you could provide touch positions as input too. This would be
neat research and I'd like to see more details.
Note however that people in the native app world believe that it's
very important that whatever applies the
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com 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
22 matches
Mail list logo
