The error message in the summary line appears in the console when I use contacts to pick a photo from gallery and select a photo and then go back to the list of photos a couple of times. My webgl code isn't shutting down correctly, it looks like. I believe this is a new error message in the console, though. I suspect that this is trivial to fix: just need to make the right webgl call to shut things down. And since I'm not confident that the error message is benign, I'm nominating it as a blocker.
Assignee: nobody → dflanagan
blocking-basecamp: --- → ?
Triage: Unless there is any direct user impact this wouldn't seem to block the release. Please renominate if there's a bigger underlying issue.
blocking-basecamp: ? → -
Sigh. This is done purposely. I don't know whether we control this per-device. AFAIK v1 target devices aren't known to limit GL contexts to a silly low number, but I also haven't tested.
Flags: needinfo?(jones.chris.g) → needinfo?(bjacob)
The mozilla-b2g18 tree does have pref("webgl.can-lose-context-in-foreground", false); in b2g/app/b2g.js. This means that it shouldn't lose WebGL contexts that are in foreground. Given that, I would like a confirmation: did you notice any adverse user-visible effect, or just that message in logcat? Losing WebGL contexts is good --- it limits memory usage and usage of potentially even scarcer resources (GL contexts). So this is only something that we need to worry about, if you noticed a real user-visible effect.
Also, to be clear, WebGL contexts go away at the first GC after the last reference to them is gone. So what likely happens is that your STR in comment 0 allow you to go over the 2 WebGL contexts per principal limit (which we arbitrarily set to avoid running into issues on some mobile devices) before GC kicks in. If you do see user-visible adverse effects, then we have plenty of options there, from increasing this limit to using a different notion than 'same principal' on B2G.
By GC I mean GC+CC --- WebGL contexts participate in a cycle with their canvas; this is cycle-collected.
Are these the same thing? can-lose-in-foreground controlled tossing contexts on memory pressure, but this sounds like something triggered by exceeding a count. (Also, the "Sigh" above was for missing the ni? request for so long :/.)
AFAIK no one has complained about this heuristic for code "in the wild", and there certainly wasn't a user-visible effect in this case.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #6) > Are these the same thing? can-lose-in-foreground controlled tossing > contexts on memory pressure, but this sounds like something triggered by > exceeding a count. Good point! I looked at the code and you're right, that pref only affects the memory-pressure event. http://hg.mozilla.org/releases/mozilla-b2g18/file/dbc39e13c7e2/content/canvas/src/WebGLContext.cpp Thinking about it more, in the present case none of the Apps in question here (Camera and Gallery) have more than 2 (in fact, more than 1) WebGL contexts in their user interface, so this code won't cause a foreground context to be lost. To have a user-visible effect, we would have to rely on background-app WebGL contexts to not get lost. Does B2G apps rely on that? (Or does B2G apps recreate WebGL contexts when they get back on foreground? (Or do they even restart from scratch?)) > > (Also, the "Sigh" above was for missing the ni? request for so long :/.) OK :-) (In reply to Chris Jones [:cjones] [:warhammer] from comment #7) > AFAIK no one has complained about this heuristic for code "in the wild", and > there certainly wasn't a user-visible effect in this case. OK, then this might be INVALID then, though I would feel more comfortable if I knew the answer to my above questions ^
Gallery no longer uses WebGL, so this bug is no longer relevant.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.