Closed Bug 1478216 Opened Last year Closed 11 months ago
Remove the (bad?) warning: This operation requires zeroing texture data
46 bytes, text/x-phabricator-request
|Details | Review|
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.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/29c73665ba19 Don't init tex images in FBAttachment::IsComplete. r=kvark
Backout by firstname.lastname@example.org: 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.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/5ef21255897e Don't init tex images in FBAttachment::IsComplete. r=kvark
You need to log in before you can comment on or make changes to this bug.