779181 - resize context to 1x1 when we forcibly lose it

Status: RESOLVED WONTFIX

(Core :: Graphics: CanvasWebGL, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: resize to 1x1

This can help with memory usage from the context if there are still oustanding refs to it, and there's no reason not to do it.

Comment 1

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

Comment on attachment 647575 [details] [diff] [review]
resize to 1x1

This will cause the main framebuffer to be immediately destroyed and recreated.

_If_ we can do that (destroy the main framebuffer immediately) even with off-main-thread-compositing, that means that we already solved the race condition problem where the compositor would access the texture during the time when it's destroyed and not yet recreated. In that case (which is where we want to go), we should not just resize the main framebuffer to 1x1, we should completely destroy the GLContext.

But, I am not sure at all that we can do that. I'm afraid that this introduces a bad race condition with the OMTC as described above.

Comment 2

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

So, we should first fix that race condition, and then we should have DestroyResourcesAndContext actually destroy the context immediately.

Since we don't want to introduce any lock that would force the compositor to wait on the main thread, we should introduce a mIsLost bit to GLContext (if it doesn't have that already), have DestroyResourcesAndContext destroy the underlying OpenGL context and set that bit, and have the compositor check for that bit;

Comment 3

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

GLContext already has bool mContextLost. Just need to hook that up.

Comment 4

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

Comment on attachment 647575 [details] [diff] [review]
resize to 1x1

What I was missing is that this is only resizing the backbuffer, which isn't what the compositor cares about in the OMTC case, thanks to double/triple buffering.

So r+ but this is only a very short-term partial fix, we should focus on the better solution of actually destroying the GL context when losing the WebGL context, as that will allow to fix issues on machines where we can't have many GL contexts live at the same time.

Comment 5

[Kelsey Gilbert [:jgilbert]]

We destroy the resources aggressively now, so this isn't useful.