Closed Bug 1478216 Opened Last year Closed 11 months ago

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

Categories

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

63 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: mozilla2, Assigned: jgilbert)

References

Details

Attachments

(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
Status: UNCONFIRMED → NEW
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!
Also:
- Only init the base tex level for GenerateMipmap.
- Change ZeroTextureData warning into a perf warning.
Status: NEW → ASSIGNED
Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/29c73665ba19
Don't init tex images in FBAttachment::IsComplete. r=kvark
Backout by dluca@mozilla.com:
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
It looks like this is actually an ANGLE bug.
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.
See Also: → 1501868
Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ef21255897e
Don't init tex images in FBAttachment::IsComplete. r=kvark
https://hg.mozilla.org/mozilla-central/rev/5ef21255897e
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.