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

Status: RESOLVED FIXED

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

Description

[Gregg Tavares]

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

Comment 1

[Jeff Gilbert [:jgilbert]]

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.

Comment 2

[Jeff Gilbert [:jgilbert]]

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?

Comment 3

[Jeff Gilbert [: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!

Comment 4

[Jeff Gilbert [:jgilbert]]

Attachment: Bug 1478216 - Don't init tex images in FBAttachment::IsComplete.

Also:
- Only init the base tex level for GenerateMipmap.
- Change ZeroTextureData warning into a perf warning.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/29c73665ba19
Don't init tex images in FBAttachment::IsComplete. r=kvark

Comment 6

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/00049c15c6e5
Backed out changeset 29c73665ba19 for mochitest failure on dom/canvas/test/webgl-conf/generated/test_2_conformance2__rendering__framebuffer-texture-changing-base-level.html

Comment 7

[Jeff Gilbert [:jgilbert]]

It looks like this is actually an ANGLE bug.

Comment 8

[Jeff Gilbert [:jgilbert]]

Worse than that, it's an old, unfixed ANGLE bug:
https://bugs.chromium.org/p/angleproject/issues/detail?id=2291

I'll file and fix this in a different bug.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ef21255897e
Don't init tex images in FBAttachment::IsComplete. r=kvark

Comment 10

[Raul Gurzau (:RaulGurzau)]

https://hg.mozilla.org/mozilla-central/rev/5ef21255897e