820015 - Error: WebGL: Exceeded 2 live WebGL contexts for this principal, losing the least recently used one.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Gallery, defect)

Description

[David Flanagan [:djf]]

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.

Comment 1

[Ben Francis [:benfrancis]]

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.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

By GC I mean GC+CC --- WebGL contexts participate in a cycle with their canvas; this is cycle-collected.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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 :/.)

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

(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 ^

Comment 9

[David Flanagan [:djf]]

Gallery no longer uses WebGL, so this bug is no longer relevant.