Optimize snapshot usage

RESOLVED FIXED in Firefox OS v1.3T

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: milan, Assigned: fabrice)

Tracking

unspecified
1.4 S1 (14feb)
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:1.3T+, b2g-v1.3T fixed)

Details

Attachments

(1 attachment)

See https://bugzilla.mozilla.org/show_bug.cgi?id=962517#c0 for the background information.

For example, snapshots during app switching are creating SkiaGL canvas - this takes more memory and doesn't actually give us performance benefit.  Bug 884226 introduced a flag willReadFrequently that we already used to fix bug 939962.  This lets us specify that we don't want SkiaGL canvas and helps us with memory usage, without the performance penalty (in fact, with performance improvements.)

Probably the wrong component, can somebody pick the right one?
We should really just demote to a software canvas immediately whenever DrawWindow is used. Shouldn't need the flag for this. If DrawWindow is the first operation, we don't even need to demote -- just the thing that prevents a hardware canvas from being created.
Component: Gaia::System → Canvas: 2D
OS: Mac OS X → Gonk (Firefox OS)
Product: Firefox OS → Core
Hardware: x86 → ARM
Assignee: nobody → snorp

Comment 2

5 years ago
We have to make sure we don't create a GLContext if you want to automate this. If you touch gl you force GL drivers to be loaded into the content process. I would like to review the patch for this bug.
My plan isn't going to work, because the snapshotter calls scale() before drawWindow(), which causes a GL context to be created first. Lose. We need a more sophisticated optimization for this, which I outlined in bug 963559. I'm putting this back in Gaia so we can do the willReadFrequently hack (as much as I hate it).
Component: Canvas: 2D → Gaia::System
Product: Core → Firefox OS
To clarify why :snorp doesn't like it - while the end result is what we want (we don't create GL canvas), in this case the reason for it isn't really because we "willReadFrequently", so it feels a bit hacky.  It would still give us the behavior we want.
Assignee: snorp → nobody
blocking-b2g: --- → 1.4?
(In reply to Milan Sreckovic [:milan] from comment #4)
> To clarify why :snorp doesn't like it - while the end result is what we want
> (we don't create GL canvas), in this case the reason for it isn't really
> because we "willReadFrequently", so it feels a bit hacky.  It would still
> give us the behavior we want.

Right. I would almost rather have another 'willUseDrawWindow' flag.

Additionally, I would really like to have an entirely separate drawWindow API that isn't reliant on canvas at all. I could just return a blob that you can then draw to a canvas if you wish, but you could also just inspect the buffer like we do for reftest, or stick it in an <img>, etc.
Probably worth filing a separate bug so that this thought doesn't get lost.

Comment 7

5 years ago
Yeah, I agree with comment 5. We should split snapshotting. Window could have a chrome only API on it. In the meantime please drive the gaia work. We need this fixed now. We should have immediately done that instead of exploring the hard route first. Lets be incremental :)
blocking-b2g: 1.4? → 1.4+
I haven't been working on this, a Gaia person should pick this up and add the 'willReadFrequently' flag as in bug 939962.
(Assignee)

Comment 9

5 years ago
Created attachment 8369559 [details] [diff] [review]
canvas-no-libegl.patch

Hi snorp, we actually do the screenshot on the chrome side (and send back a blob).
Assignee: nobody → fabrice
Attachment #8369559 - Flags: superreview?(snorp)
(Assignee)

Updated

5 years ago
Whiteboard: [tarako][POVB]
Comment on attachment 8369559 [details] [diff] [review]
canvas-no-libegl.patch

Review of attachment 8369559 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good
Attachment #8369559 - Flags: superreview?(snorp) → superreview+
https://hg.mozilla.org/mozilla-central/rev/ed9eececa94c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S1 (14feb)
marking 1.3T+ as it's in tarako branch
blocking-b2g: 1.4+ → 1.3T+
Whiteboard: [tarako][POVB] → [POVB]

Updated

5 years ago
Component: Gaia::System → DOM
Product: Firefox OS → Core
Whiteboard: [POVB]
You need to log in before you can comment on or make changes to this bug.