Closed Bug 1478216 Opened 3 years ago Closed 2 years ago

Remove the (bad?) warning: This operation requires zeroing texture data


(Core :: Canvas: WebGL, defect, P3)

63 Branch



Tracking Status
firefox65 --- fixed


(Reporter: mozilla2, Assigned: jgilbert)




(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce:

call `gl.texImage2D` with null and later use that texture

Actual results:

I get a warning in the console that confuses developers and users alike

Expected results:

No warning for a perfectly valid use case

Creating textures with no data is a common use case for making textures to be attached to framebuffers as render targets or for textures with scrolling data (only updating the newest line of a data). You shouldn't get a warning for this. Preventing the warning is actually slower which would require creating a TypedArray in JavaScript which requires the browser to both allocate the memory AND allocate the typedarray object to view that memory AND allocate the corresponding arraybuffer object track that memory. It then requires the browser to track the references so it can later free a 3 objects. It doesn't seem to make sense to tell developers to do this vs letting WebGL clear these textures for it.

See mozilla-central/dom/canvas/WebGLTexture.cpp line 644
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
Ever confirmed: true
Priority: -- → P3
We want to surface to devs when unexpected work is being done. Ideally we have apps do the clears eagerly, instead of waiting on webgl to do them. In particular, many of these clears in WebGL we do by allocing zeros and uploading them, whereas apps should be clearing the resources before use.

The issue here is that we are lazily clearing before clears, and chiding devs who dare to do so! :)
Clears should not warn here.
As of bug 1498070, this warning is now only generated for partial tex image uploads, not framebuffer draws.
It doesn't seem like this made it into Nightly yet though?
Assignee: nobody → jgilbert
It did, but we're still hitting it through a round-about way:
Our framebuffer completeness check checks for texture base-level completeness, initializing any uninitialized levels. Oops!
- Only init the base tex level for GenerateMipmap.
- Change ZeroTextureData warning into a perf warning.
Pushed by
Don't init tex images in FBAttachment::IsComplete. r=kvark
Backout by
Backed out changeset 29c73665ba19 for mochitest failure on dom/canvas/test/webgl-conf/generated/test_2_conformance2__rendering__framebuffer-texture-changing-base-level.html
It looks like this is actually an ANGLE bug.
Worse than that, it's an old, unfixed ANGLE bug:

I'll file and fix this in a different bug.
See Also: → 1501868
Pushed by
Don't init tex images in FBAttachment::IsComplete. r=kvark
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.