Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 121405 Canvas render beyond 8192px fails
Starred by 3 users Reported by mar...@webtreeprint.com, Apr 2 2012 Back to list
Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jan 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows
Pri: 2
Type: Bug



Sign in to add a comment
Chrome Version       : 18.0.1025.142
OS Version: 5.1 (Windows XP)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 8.x: OK
 Firefox 11.0: OK
IE 7/8/9:

What steps will reproduce the problem?
1. Run the attached test file test_canvas.html

This looks like a fairly fundamental bug - the attached test file draws rectangles, lines and text at intervals across the canvas. 

Running this on a Windows XP machine, no hardware acceleration, the rectangles and lines fail to render after 8000px. Text however is rendered correctly. In addition:

1. A vertical line is rendered at position 1px left
2. The canvas border fails to render top and bottom, but left and right remain.
3. The browser window has no horizontal scroll bar, which can be recovered by maximize/minimize the window.

If you increase the size of the test (20000 canvas width, loop i<100) then some of the later rendered boxes 'wrap around' to the beginning of the canvas.

Playing around with the figures the limit appears to be 8192 (which may be significant) - in fact if you set the drawRect to be x = (i*200)+92 so that the right edge of a rectangle falls on 8192 then this will crash Chrome.

This bug appears to have been introduced with version 17 - previous versions were OK.

UserAgentString: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19



 
test_canvas.html
1.3 KB View Download
 Issue 109275  sounds like it might be related.
Labels: Feature-GPU-Canvas2D
Cc: bsalomon@chromium.org tomhud...@chromium.org
On Windows XP there is no hardware acceleration (as you note), so this isn't related to hardware accelerated Canvas. Does it work on Canary? Since you note that this was introduced in 17, can you run bisect_builds to identify a regression range where the problem was introduced? I don't have an XP machine handy to do so. Thanks,
Tried the test on Canary (20.0.1089.0), and it fails the same. Sorry, but I don't understand the second bit about bisect_builds ...
Comment 5 by dharani@google.com, Apr 2 2012
Cc: anan...@chromium.org
anantha@: can you please get this bisected? thanks!
Owner: tomhud...@chromium.org
Status: Untriaged
Bisecting...
Labels: -Area-Undefined -Feature-GPU-Canvas2D Area-Internals Internals-Skia OS-Linux
Replicates in Linux stable & Win Canary with software rendering.
Also replicates in Win Canary with hardware rendering.
bisecting points to http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=123995:124002

This range includes a Skia roll 3244->3271; 3271 changed how we do overflow checking of antialiased paths, so is a possible suspect.

Cc: reed@chromium.org
Status: Assigned
We're given a 10k pixel wide canvas, and the antialiased clipping code can't clip anything bigger than 8k. The failover to a non-antialiased clip was removed over a series of changes ending in 3271, and the attempt to early out introduced in 3271 doesn't seem to be catching this case - it's bounds-checking against 0x20000000 instead of 0x2000.

If it's urgent I could work on this immediately, but since this is P2, my intent is to have Mike advise on it Monday.

Status: Started
We're looking at a 3-part solution:
1. disable antialiasing when we're rendering to a canvas beyond x=8191 or y=8191
2. "tiling special case"; works if the path to be rendered is smaller than 8192x8192, regardless of canvas size
3. general tiling of antialiased rendering

#1 would be committed ASAP to fix this bug; #2 and #3 would be low-priority future work. Unfortunately, a straightforward version of #1 regresses rendering for sites like Google Maps, which may be rendering a tiny portion of a very large path, and a slightly more complicated approach (http://codereview.appspot.com/5989070/) breaks the fast/box-shadow/* layout tests. We're working to understand how those layout tests break and what the correct semantics for them are.
#1 is now in Skia as revision 3658, and should roll into the Chrome canary within a couple of business days.
Thanks for the work on this - I'll check out Canary in a couple of days.
Thanks guys, works great (Canary 20.0.1101.1).

It's not important for me, but what I thought were side effects of this issue (my items 2 & 3) are still present -

2. It fails to render a border top & bottom (left & right are OK) on a canvas larger than 8192.

3. The horizontal scroll bar disappears at intervals as you change the size of the browser window. Subsequent checks show this is unrelated to Canvas, but seems to be a general Chrome problem on Windows XP 32bit, but not Windows 7 64bit.

I will leave it up to you if you want to raise new issues for these.
Status: Verified
Sounds like this was verified back in M20, although we may need a couple of new bugs.
Project Member Comment 15 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Skia Cr-Internals Cr-Internals-Skia
Sign in to add a comment