The default bug view has changed. See this FAQ.

When trying to create a too large canvas, don't throw, instead just use a smaller drawing buffer

RESOLVED FIXED in mozilla10

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bjacob, Assigned: jgilbert)

Tracking

unspecified
mozilla10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 5 obsolete attachments)

We currently file a few WebGL conformance tests, like

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/canvas/drawingbuffer-static-canvas-test.html

Because we throw on canvas.width = something_huge when SetDimensions fails.

Chrome doesn't throw there.

Chrome also won't use a drawingbuffer larger than the max texture size or 4k, whichever is smaller.

We need to fail less on resizing-canvases-to-large-sizes by using a smaller drawingbuffer if needed.
(Assignee)

Updated

6 years ago
Blocks: 615976
No longer blocks: 680721
(Assignee)

Updated

6 years ago
Blocks: 680721
(Assignee)

Updated

6 years ago
Depends on: 688112
(Assignee)

Updated

6 years ago
Assignee: nobody → jgilbert
(Assignee)

Updated

6 years ago
Blocks: 688112
No longer depends on: 688112
(Assignee)

Comment 1

6 years ago
Created attachment 564827 [details] [diff] [review]
Fixes GLContext::ResizeOffscreen leaving a mess on failure

This change basically guarantees that GLContext will not be changed if a resize attempt fails.
(Assignee)

Updated

6 years ago
Blocks: 685229
(Assignee)

Comment 2

6 years ago
It didn't occur to me before that the arguably time-saving initialize once approach was incompatible with soft-failing resizing.
Updated try: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=322fe6cae175
(Assignee)

Comment 3

6 years ago
Yeah, that didn't work so well. 
Updated:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=089d1b13072f
(Assignee)

Updated

6 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

6 years ago
Created attachment 566099 [details] [diff] [review]
Guarantees that GLContext::ResizeOffscreen is harmless if it fails

Current patch file.
Attachment #564827 - Attachment is obsolete: true
Attachment #566099 - Flags: review?(bjacob)
(Assignee)

Updated

6 years ago
Attachment #566099 - Flags: review?(bjacob) → feedback?(bjacob)
(Assignee)

Comment 5

6 years ago
Ran into a problem on OS X.
(Assignee)

Comment 6

6 years ago
Created attachment 566404 [details] [diff] [review]
Guarantees that GLContext::ResizeOffscreen is harmless if it fails

Fixed CGL impl.
Attachment #566099 - Attachment is obsolete: true
Attachment #566099 - Flags: feedback?(bjacob)
Attachment #566404 - Flags: review?(bjacob)
(Assignee)

Comment 7

6 years ago
New try run:
https://tbpl.mozilla.org/?tree=Try&rev=5a9f76410202
(Assignee)

Comment 8

6 years ago
For some reason my last changes reset. Maybe I reset my patch file somehow.
Updated try with CGL fix:
https://tbpl.mozilla.org/?tree=Try&rev=ff8c9387530d
(Assignee)

Comment 9

6 years ago
Created attachment 567141 [details] [diff] [review]
Guarantees that GLContext::ResizeOffscreen is harmless if it fails

Fixed errant tab issues and added further commenting.
Attachment #566404 - Attachment is obsolete: true
Attachment #566404 - Flags: review?(bjacob)
Attachment #567141 - Flags: review?(bjacob)
(Assignee)

Comment 10

6 years ago
Created attachment 567147 [details] [diff] [review]
Guarantees that GLContext::ResizeOffscreen is harmless if it fails

Predicates too-verbose debug printf on mDebugMode.
Attachment #567141 - Attachment is obsolete: true
Attachment #567141 - Flags: review?(bjacob)
Attachment #567147 - Flags: review?(bjacob)
Comment on attachment 567147 [details] [diff] [review]
Guarantees that GLContext::ResizeOffscreen is harmless if it fails

Review of attachment 567147 [details] [diff] [review]:
-----------------------------------------------------------------

This looks all good!

Just one remark about something to keep in mind. The ClearSafely() call is mega-super-important for security: we must prevent WebGL scripts from reading back uninitialized video memory from a newly resized canvas. In your AA patches, the FBO becomes two separate FBOs, right. So will we need two ClearSafely() calls there?
Attachment #567147 - Flags: review?(bjacob) → review+
(Assignee)

Comment 12

6 years ago
> Just one remark about something to keep in mind. The ClearSafely() call is
> mega-super-important for security: we must prevent WebGL scripts from
> reading back uninitialized video memory from a newly resized canvas. In your
> AA patches, the FBO becomes two separate FBOs, right. So will we need two
> ClearSafely() calls there?

I will triple-check, but we shouldn't need to. After clearing the draw buffer, the read buffer /may/ be uninitialized, but before any read call is possible, we blit over the cleared draw buffer, clearing the read buffer. Basically, it's only possible to access if you can read it without using GL commands to do so. We could just deliberately blit over the cleared draw buffer, as that should be minimal cost compared to assembling a resized buffer, but it should not be necessary. If it were necessary, there would be other problems with our WebGL restrictions anyways.
(Assignee)

Comment 13

6 years ago
Created attachment 567820 [details] [diff] [review]
Guarantees that GLContext::ResizeOffscreen is harmless if it fails

Carrying forward r+ from bjacob after PR_TRUE/FALSE conversion.
Attachment #567147 - Attachment is obsolete: true
Attachment #567820 - Flags: review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/8583488f5241
Re-landed with proper commit message (sorry, should have checked that)
http://hg.mozilla.org/integration/mozilla-inbound/rev/716915ed489c
https://hg.mozilla.org/mozilla-central/rev/716915ed489c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
(Assignee)

Updated

6 years ago
Duplicate of this bug: 688112
(Assignee)

Updated

5 years ago
Duplicate of this bug: 685229
(Assignee)

Updated

5 years ago
Duplicate of this bug: 723072
You need to log in before you can comment on or make changes to this bug.