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
On Mon, Feb 23, 2015 at 4:26 PM, Jonas Sicking wrote:
> On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan
> wrote:
>> 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 resilie
LCD monitor 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://
In Gecko, we will only decode images on the main thread:
(1) If they’re very small and this is the first time we’re decoding them and
our heuristics suggest that decoding them quickly is important.
(2) If it’s absolutely required because of a synchronous API, e.g.
canvas.drawImage.
We’ve been g
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 r
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 th
> 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.
>
>
How should we explain the CSS
On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan wrote:
> 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
> 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 wou
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
Le 24 févr. 2015 à 08:02, Robert O'Callahan a écrit :
> 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 netwo
On Mon, Feb 23, 2015 at 3:02 PM, Robert O'Callahan wrote:
> 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
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
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.
While I very much want the ideal to
On Mon, Feb 23, 2015 at 12:07 PM, Robert O'Callahan
wrote:
> 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 yo
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 any
> worse.
>
> I agree that it'
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
On Mon, Feb 23, 2015 at 11: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 new
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-feed content that's currently on
the screen, or the event invitation
A couple thoughts from the perspective of a web app dev who has struggled with
this problem:
I get excited when I hear a proven solution with well-understood scope like
“animations and user interactions on the same thread”. I get nervous about
ambitious and unknown solutions (async DOM). The we
What does it mean to "save your 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 wrote:
> On Sun, Feb 22, 2015
On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan wrote:
> 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 the
of anything that couldn't be
> implemented with a combination of #1 and #3. 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).
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
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.
>
-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
> wrote:
>> Le 20/02/2015 04:25, Robert O'Callahan a écrit :
>>> On Fri, Feb 20, 2015 at 4:02 PM, James Long
>>> wrote:
>>>
>>> Personally I think what w
On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg wrote:
> Le 20/02/2015 04:25, Robert O'Callahan a écrit :
>> 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
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
> 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 #
On Fri, Feb 20, 2015 at 3:20 AM, Jonas Sicking wrote:
> On Thu, Feb 19, 2015 at 7:11 PM, James Long 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 v
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 pla
On Fri, Feb 20, 2015 at 3:27 AM, Robert O'Callahan 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 render
> to canvas
On Thu, Feb 19, 2015 at 7:11 PM, James Long 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.
Does that mea
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
On Thu, Feb 19, 2015 at 10:25 PM, Robert O'Callahan
wrote:
> 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 dire
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
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 animatio
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 s
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
38 matches
Mail list logo
