resize context to 1x1 when we forcibly lose it

NEW
Assigned to

Status

()

Core
Canvas: WebGL
5 years ago
4 years ago

People

(Reporter: vlad, Assigned: vlad)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: webgl-internal)

Attachments

(1 attachment)

Created attachment 647575 [details] [diff] [review]
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.
Attachment #647575 - Flags: review?(bjacob)
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.
Attachment #647575 - Flags: review?(bjacob) → review-
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;
GLContext already has bool mContextLost. Just need to hook that up.
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.
Attachment #647575 - Flags: review- → review+
Whiteboard: webgl-internal
You need to log in before you can comment on or make changes to this bug.