Bug 98600
| Summary: | Canvas won't refresh without hacks | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ken Tozier <kentozier> |
| Component: | Canvas | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Major | ||
| Priority: | P2 | ||
| Version: | 525.x (Safari 3.2) | ||
| Hardware: | Mac (Intel) | ||
| OS: | OS X 10.8 | ||
Ken Tozier
I'm writing a large, complex canvas based Javascript class and have found that in WebKit browsers (Safari, Chrome) The only way I can get user actions to display is the following ugly hack on every single draw event
canvas.width = canvas.width + 1
canvas.width = canvas.width - 1
<do rest of drawing>
I tried the slightly less ugly
canvas.width = canvas.width + 0
but that didn't work. Only the forced resizing of the canvas does the trick. My class fills the entire window and can contain hundreds or thousands of elements that need drawing, so forcing this sort of refresh is very computationally expensive.
I've tried for two days to use more efficient clearing/redrawing only the small portions of the canvas that actually contain changes, but nothing works except the above. I suspect some sort of optimization is rolled into the WebKit implementation to only draw in response to major canvas changes, but it seems like it would be far more optimal to get sub-canvas refreshing working.
The working code is quite large (450K) and really can't be distilled to a small snippet as there's too much interdependency between classes. If necessary, though, I can supply it to help with figure out this bug.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ken Tozier
I rewrote my drawing code and it seems to have resolved the issue.