bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

WebGL unintended clearing issue

RESOLVED WORKSFORME

Status

()

Core
Canvas: WebGL
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: Bart van Andel, Unassigned)

Tracking

22 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: webgl-correctness)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

We are developing a WebGL based panorama viewer, which only draws frames when the view parameters change (i.e., yaw, pitch, field of view, or canvas size). In between those draw actions, we do not touch the WebGL context.


Actual results:

When no frames are explicitly drawn by us, the viewer sometimes blanks all of a sudden.


Expected results:

The previously drawn frame should stay visible.
(Reporter)

Comment 1

5 years ago
This issue did not happen in FF21, it started to happen after the update to FF22. I've tried to reproduce the issue in the portable versions of FF21 (ok), FF22 (not ok), and FF23beta1 (not ok).

We don't have any of our own code at hand, but the issue is also reproducible with the WebGL rotating cube demo by Mozilla itself (https://developer.mozilla.org/samples/webgl/sample6/index.html). After clearing the timeout which makes the cube rotate (i.e. using the FireBug developer console: clearTimeout(some number)), the canvas may turn black at some point. It is not exactly clear when this happens, but we can reproduce the issue quite easily by opening another tab with another WebGL demo, and switch a few times between those tabs.

NB: the color by which the viewport is cleared appears to be transparent black (0,0,0,0), irrespective of any clear color actually set. This has been tested by setting a different color using gl.clearColor(...), enabling/disabling the alpha parameter at creating time of the webgl context, playing around with the background color behind the canvas, etc.

Since it only happens in FF22 (and 23beta1) and not in earlier versions, I suspect it has something to do with the recent performance improvement mentioned in the release notes and discussed in issue #829747.

No GL errors show up anywhere.

Our hardware configuration:
Workstation model: Dell Precision M6600
CPU: Intel Core i7-2720QM
RAM: 8GM
GPU: NVIDIA Quadro 3000M
OS: Windows 7 Professional, all MS updates applied
Driver: official NVIDIA driver, 310.90. Also tested with the current release (320.49)
(Reporter)

Comment 2

5 years ago
Forgot to mention: everything was tested in 64 bit versions.
(Reporter)

Comment 3

5 years ago
Whoops. "clearTimeout" should be "clearInterval" obviously.
(Reporter)

Comment 4

5 years ago
I just found out that this behavior can be counteracted by setting the variable "preserveDrawingBuffer" to true on initialization of the context:

var gl = canvas.getContext("experimental-webgl", {
        preserveDrawingBuffer: true
    });

Has the default value changed with the release of FF22? Or is this just a coincidence?

Updated

5 years ago
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
(In reply to Bart van Andel from comment #4)
> I just found out that this behavior can be counteracted by setting the
> variable "preserveDrawingBuffer" to true on initialization of the context:
> 
> var gl = canvas.getContext("experimental-webgl", {
>         preserveDrawingBuffer: true
>     });
> 
> Has the default value changed with the release of FF22? Or is this just a
> coincidence?

The default has not changed, and has always been 'false'. 

I can reproduce this, so I'll take a look at it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → bug 917160
Whiteboard: webgl-correctness
Fixed by 917160. Please reopen if you can still reproduce it.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.