On Mon, Feb 23, 2015 at 01:13:02AM -0800, Nicholas Nethercote wrote:
> On Sun, Feb 22, 2015 at 10:46 PM, Mike Hommey wrote:
> >>
> >> We've had increasing numbers of cases lately on Windows where memory
> >> usage goes out of control but the existing memory reporters (e.g. the
> >> "explicit" tree
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
Axel> The other "easy" way to reduce impact here is to reduce the use of
Axel> nsTextFormatter, or create a replacement that doesn't crash. L20n
Axel> would be one, or maybe there's C++ template stuff that can "taint"
Axel> values with their original types.
Tom> I don't think there is a compile-ti
Test Informant report for 2015-02-22.
State of test manifests at revision 86d2bb8bb1c9.
Using revision e0cb32a0b1aa as a baseline for comparisons.
Showing tests enabled or disabled between 2015-02-14 and 2015-02-22.
85% of tests across all suites and configurations are enabled.
Summary
---
Hi Laurent,
The problem that you seem to be running into is the fact that
application bundles (Firefox) and framework bundles (xulrunner) differ
in their file organization [1]. They used to be identical prior to
Firefox 34, but as you can see in the bugs that you referenced, a change
to the struct
On Friday, February 20, 2015 at 10:50:12 AM UTC+1, 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
> unex
On Sun, Feb 22, 2015 at 10:46 PM, Mike Hommey wrote:
>>
>> We've had increasing numbers of cases lately on Windows where memory
>> usage goes out of control but the existing memory reporters (e.g. the
>> "explicit" tree in about:memory) doesn't show anything. This is
>> because the memory usage is
25 matches
Mail list logo
