Closed
Bug 1478216
Opened 7 years ago
Closed 7 years ago
Remove the (bad?) warning: This operation requires zeroing texture data
Categories
(Core :: Graphics: CanvasWebGL, defect, P3)
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
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Assignee | ||
Comment 1•7 years ago
|
||
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.
Assignee | ||
Comment 2•7 years ago
|
||
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
Assignee | ||
Comment 3•7 years ago
|
||
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!
Assignee | ||
Comment 4•7 years ago
|
||
Also:
- Only init the base tex level for GenerateMipmap.
- Change ZeroTextureData warning into a perf warning.
Assignee | ||
Updated•7 years ago
|
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
Assignee | ||
Comment 7•7 years ago
|
||
It looks like this is actually an ANGLE bug.
Assignee | ||
Comment 8•7 years ago
|
||
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 jgilbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ef21255897e
Don't init tex images in FBAttachment::IsComplete. r=kvark
Comment 10•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in
before you can comment on or make changes to this bug.
Description
•