| Summary: | [iOS] Max canvas size is lower than expected | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dean Jackson <dino> | ||||
| Component: | New Bugs | Assignee: | Dean Jackson <dino> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | commit-queue, esprehn+autocc, graouts, gyuyoung.kim | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Dean Jackson
2015-02-22 18:38:31 PST
Created attachment 247091 [details]
Patch
While I greatly appreciate this limit being bumped to a more accurate limit, what exactly is the purpose of the limit? Is it for performance reason? Memory consumption reasons? If so, why not let content degrade and/or jetsam if values are too large? Especially as there is no mechanism in place to predictably figure out, in code, whether a given <canvas> size will actually allow the content to be rendered. (In reply to comment #2) > While I greatly appreciate this limit being bumped to a more accurate limit, > what exactly is the purpose of the limit? Is it for performance reason? > Memory consumption reasons? If so, why not let content degrade and/or jetsam > if values are too large? Especially as there is no mechanism in place to > predictably figure out, in code, whether a given <canvas> size will actually > allow the content to be rendered. I tried Firefox and it fails silently when the canvas gets too big, like us. So I think it is worth keeping a limit in, just in case. Note that it's a pretty bad developer experience if their page instantly quits/crashes - that gives them no way to debug without removing random code and starting over. At least with a large limit they'll get a warning in the console as to what went wrong. Committed r180520: <http://trac.webkit.org/changeset/180520> |