This app doesn't work with the latest canary (17.0.942.0), with or without accelerated canvas.  It fails to respond to mouse input.  Also the color picker on the left column doesn't appear.

Anantha, can we please we get some help in bisecting to figure out when things stopped working?

It also doesn't display right in 15 stable; the left column has two copies of the same controls, one down and to the right of the other. Clicking e.g. the text icon makes another duplicate set of controls. Can't draw anything.

Here's a simple test case that might be the same problem (the latency, that is, not the current brokenness).

canvas-mouse-latency.html 574 bytes View Download

Running on 64bit linux machine.

The app worked fine in 14.0.835.202

The app had noticeable latency in 15.0.874.1-r99955 and .5-r100117 switching from the spray paint to the pencil and drawing with the pencil.

There is minor latency improvement in 16.0.889.0-r102207

The last time the app worked was in build 16.0.899.0-r103668

The app stopped working in 16.0.940.0-r104662

Thanks, dyu@ .  Were you checking with accelerated canvas on or off?

off

Unable to draw anything in the Sketchpad on 18.0.1006.0 (Official Build 117612) canary (Canvas: Hardware accelerated).
This looks fine on 16.0.912.75 (Official Build 116452) m (Canvas: Software only. Hardware acceleration disabled.) with out even enabling the GPU Accelerated Canvas 2D flag in chrome://flags.

I'm not able to draw anything on the canvas even when I disable accelerated canvas (--disable-accelerated-2d-canvas) .  Can you please try that too? 

 Issue 124590  has been merged into this issue.

I work on that app -- I'll post an update in about two weeks.
The issue is still present, but the lag is not as bad in M20.

-Charles

For latency perf graphs, see:
http://build.chromium.org/f/chromium/perf/gpu-fyi-win7-release-intel/gpu_latency/report.html?history=150&rev=-1&graph=webgl

Key for graphs:
http://www.chromium.org/developers/how-tos/gpu-wrangling (see gpu_latency_tests section).

Note that the GPU path is at least 1 frame more than software by design (renderer kMaxSwapBuffers == 2 which overlaps webkit rendering code with previous frame's GL command processing). This design is a direct trade-off between throughput and latency. Unfortunately, pages with cheap rendering costs (that could fit both webkit and GL commands in less than 16.6ms) still get the extra frame of latency because we do not dynamically reduce kMaxSwapBuffers.

There is also an additional frame of latency if you consider the double-buffered platform swaps which we are typically backed up on. This may be improved by the compositor thread (currently off by default) or vsync-based RAF-scheduling.

Both the software and GPU path are affected by input queuing/coalescing by the browser process, which often adds 1 frame of latency.

As shown in the latency perf graphs, the javascript input handler behavior can have a significant effect on input latency (ih = Input handler is Heavy; id = Input handler Dirty's the DOM). The best thing to do in your input handler is store the mouse data and return. Then handle them during requestAnimationFrame.

Big thanks on investigating. I will focus on this when I'm back in the office. It does seem that Chrome Windows has higher latency than my OS X.

I've found that rAF with a setTimeout of 20ms seems to bring the best balance between latency and loss of accuracy. But that's not the topic at hand. Rendering does result in the loss of pointer events. I'm just bringing that point up to agree completely that rAF scheduling with a point queue is the way to go with raster-oriented drawing apps. We found that out with wacom tablets which process a good 10x more events than a typical mouse.

It does appear on OS X that I'm only looking at a 2 - 3 frame lag, but it seems as though on Windows over 4 frames or 60ms. Anyway, I'll do my best to figure this out. A 60ms lag seems to slow for things like media synchronization. I'm certain that it's not simply a 16ms lag as 60fps is just fine; 15 fps is not.

This issue seems to be fixed in Win 7 Canary M21.0.1151.1+. Very noticeable difference between M19 and M21. 

A change that went into Canary 21.0.1151.1 is that deferred 2d canvas rendering was turned on by default.  I tried verifying whether this feature is what solves the problem, but I am finding it hard.  Latency feels snappy to me even in M19.  Maybe because I have an untrained eye, or maybe because my machine rocks, I dunno.

Anyways, @downchuck, can you try running the latest canary with the command line switch --disable-deferred-2d-canvas

If doing that brings back the latency suckiness, then we'll know what fixed this.  Thanks.

Looks like the switch is now in about:flags.

My Canary M21 is running Canvas in software only mode, whereas M19 is running with hardware acceleration. I forced M21 to run with Canvas with hardware acceleration and the latency returned. I turned on and off deferred 2d canvas -- it didn't make a noticeable difference either way. I notice the latency because the drawing lags behind the mouse cursor, it looks animated. With software rendering, it's immediate and I'm not able to "outrun" drawing with the mouse.

M21 GPU disabled on my system per issue #116350

One more note: the IE Fish Tank demo performs quite a bit better in M19+GPU, it performs about 20% slower with M21+GPU and quite a bit slower with GPU disabled, on this machine.

 Issue 154265  has been merged into this issue.

I noticed in current beta channel,even if disable accelerated 2D canvas,the latency will also appear if the page contains flash content.(not only PPAPI Flash but also NPAPI flash).
Does it related to flash or <object> tag?
Here is the test case.

canvastest.html 2.4 KB View Download

I believe you'll see it any time the GPU compositor is triggered. GPU-canvas and PPAPI flash trigger it for sure. I think NPAPI flash does as well but I'm not 100% sure. You can force the compositor on in chrome:://flags ("GPU compositing on all pages").

Tried disable "GPU compositing on all pages" and "Threaded compositing" in about:flags but seems no use.

Hopes this feedback can help to fix this issue.

In latest Google Chrome	24.0.1312.5 (Official Build 166104) beta-m
Even enable --disable-accelerated-2d-canvas,this issue can also be reproduced.

@ratsunny, can you please post the contents of your about:gpu page? 

Graphics Feature Status
Canvas: Software only. Hardware acceleration disabled.
Compositing: Hardware accelerated on all pages and threaded
3D CSS: Hardware accelerated
CSS Animation: Accelerated and threaded
WebGL: Hardware accelerated
WebGL multisampling: Hardware accelerated
Flash 3D: Hardware accelerated
Flash Stage3D: Hardware accelerated
Texture Sharing: Hardware accelerated
Video Decode: Hardware accelerated
Video: Hardware accelerated
Panel Fitting: Unavailable. Hardware acceleration disabled.
Problems Detected
Enable panel fitting capability on ChromeOS only on Ivy Bridge Graphics Controller.
Accelerated 2D canvas is unavailable: either disabled at the command line or not supported by the current system.
Panel fitting is unavailable, either disabled at the command line or not supported by the current system.
Version Information
Data exported	11/10/2012 12:31:27 AM
Chrome version	24.0.1312.5 (Official Build 166104) beta-m
Operating system	Windows NT 6.1 SP1
Software rendering list version	4.2
ANGLE revision	1318
2D graphics backend	Skia
Performance Information
Graphics	4.2
Gaming	6.2
Overall	4.2
Driver Information
Initialization time	745
Sandboxed	false
GPU0	VENDOR = 0x8086, DEVICE= 0x0046
Optimus	false
AMD switchable	false
Driver vendor	Intel Corporation
Driver version	8.15.10.2622
Driver date	1-10-2012
Pixel shader version	3.0
Vertex shader version	3.0
Machine model	
GL version	
GL_VENDOR	
GL_RENDERER	
GL_VERSION	
GL_EXTENSIONS	
Diagnostics
0
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	10
dwHeight	768
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1366
iAdapter	0
lDriverSize	581120
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	Intel(R) HD Graphics (Core i5)
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Internal
szDDIVersionEnglish	10
szDDIVersionLocalized	10
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C ModeWMV9_B ModeWMV9_C ModeVC1_B ModeVC1_C
szDescription	Intel(R) HD Graphics
szDeviceId	0x0046
szDeviceIdentifier	{D7B78E66-4306-11CF-CD79-2834B2C2C535}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	1174 MB
szDisplayMemoryLocalized	1174 MB
szDisplayModeEnglish	1366 x 768 (32 bit) (60Hz)
szDisplayModeLocalized	1366 x 768 (32 bit) (60Hz)
szDriverAssemblyVersion	8.15.10.2622
szDriverAttributes	Final Retail
szDriverDateEnglish	1/10/2012 14:12:26
szDriverDateLocalized	2012/1/10 14:12:26
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.1
szDriverModelLocalized	WDDM 1.1
szDriverName	igdumdx32.dll,igd10umd32.dll
szDriverNodeStrongName	oem25.inf:IntelGfx.NTx86.6.0:iILKM0:8.15.10.2622:pci\ven_8086&dev_0046
szDriverSignDate	
szDriverVersion	8.15.0010.2622
szKeyDeviceID	Enum\PCI\VEN_8086&DEV_0046&SUBSYS_14221043&REV_12
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{AA1A63B1-EB5E-4673-814C-3344545B1E4C}\0000
szManufacturer	Intel Corporation
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Supported
szRankOfInstalledDriver	00E62001
szRegHelpText	
szRevision	
szRevisionId	0x0012
szSubSysId	0x14221043
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	n/a
szVendorId	0x8086

Crash List
624fdaeb957fce7f: Friday, November 9, 2012 11:20:10 PM
1ded23a5bad04f08: Wednesday, November 7, 2012 11:41:55 AM
13fc1c57eaeb6099: Wednesday, October 31, 2012 1:25:22 PM
49602e840c61cd1a: Wednesday, October 31, 2012 9:19:45 AM
5efd1d1fbd756a77: Tuesday, October 30, 2012 10:30:17 PM
5b448bb76cd379ff: Sunday, October 28, 2012 10:34:22 AM
e79b329b9943ffc9: Sunday, October 28, 2012 8:24:18 AM
ef74fe7543e10223: Saturday, October 27, 2012 9:05:28 AM
629623b50d395fbb: Wednesday, October 24, 2012 10:51:53 PM
aa933ea89705cbf9: Wednesday, October 24, 2012 12:24:33 AM
fe3ff118b818dfa5: Tuesday, October 23, 2012 6:13:47 AM
32bf41c0779a2ee5: Friday, October 19, 2012 6:19:25 AM
18d5aafd8ffa3ed7: Monday, October 15, 2012 4:27:47 PM
d90bab89ec1e3d0f: Monday, October 15, 2012 5:08:28 AM
98767ba7b621dd38: Sunday, October 14, 2012 9:39:30 PM
17002042d6a602d8: Saturday, October 13, 2012 8:11:36 PM
99ce9e5157453b98: Saturday, October 13, 2012 8:08:55 PM
fbdf5bb0cfa92953: Saturday, October 13, 2012 8:07:58 PM
58b5fab45b807490: Saturday, October 13, 2012 1:20:21 PM
c4ba799a7f897a2c: Saturday, October 13, 2012 10:27:14 AM
89e501e1fd336260: Saturday, October 13, 2012 7:44:48 AM
670cce2e0e8f2d94: Saturday, October 13, 2012 2:16:10 AM
4dcc0677958f8892: Friday, October 12, 2012 11:54:14 PM
a91a28e0aa6672a2: Friday, October 12, 2012 8:27:38 AM
dc2f8f7ffc2104b4: Thursday, October 11, 2012 4:07:28 PM
511aff7b8b12a080: Thursday, October 11, 2012 3:22:18 AM
94efde9c9e4e0212: Tuesday, October 9, 2012 10:21:06 PM
adfad26cb0b9b1b4: Tuesday, October 9, 2012 5:13:00 PM
81ea9336b5e2efbb: Tuesday, October 9, 2012 2:43:26 AM
24ea0b206a8893da: Monday, October 8, 2012 6:18:51 AM
e142f30f1fcded0c: Saturday, October 6, 2012 6:29:23 PM
fcc39b516632444e: Saturday, October 6, 2012 12:30:31 PM
f4c6fda7b025d776: Thursday, September 27, 2012 3:22:09 PM
92ca88d65c80c22b: Friday, September 7, 2012 1:27:54 PM
38dfbaf1f740231c: Thursday, September 6, 2012 1:01:44 PM
bff5040f27ebde58: Friday, August 31, 2012 1:41:23 AM
18dc43f016763d10: Monday, August 27, 2012 1:32:30 PM
4d2bd4de91a718a7: Monday, August 27, 2012 1:31:02 PM
bd7e0601199e1985: Monday, August 27, 2012 1:28:54 PM
947c42b62118920c: Sunday, August 26, 2012 2:55:33 AM
c03aacdc611810e1: Thursday, August 16, 2012 5:22:40 PM
c97254d7e7edd1ff: Saturday, July 21, 2012 11:24:10 PM
857238f2a2d59ed5: Tuesday, July 17, 2012 12:32:15 AM
Log Messages
[11792:11796:1109/221921:ERROR:gl_surface_egl.cc(412)] : Error: surface has zero area 0 x 0
[11792:11796:1109/221921:ERROR:gl_surface_egl.cc(477)] : Failed to resize pbuffer.
[11792:11796:1109/223816:ERROR:gl_surface_egl.cc(412)] : Error: surface has zero area 0 x 0
[11792:11796:1109/223816:ERROR:gl_surface_egl.cc(477)] : Failed to resize pbuffer.


My notebook use NV Optimus technology.
On only text page this issue also can be reproduced.

Interesting, than you. It looks like we're not properly detecting that you're running on an Optimus GPU.  Do you know whether chrome is using the integrated or the discrete part? 

In my NV Driver,Chrome default to use integrated GPU(By auto-selected).
And in NV Driver monitor,Chrome seems using integrated also.
I tried force it to use discrete GPU and it works(In driver monitor I can see Chrome is using my GT335),but this issue can also reproduced.

This seems to have been broken again in M26 release; it's destroyed the responsiveness of a Canvas based drawing app.

See: http://r1.s.mugtug.com/ink

downchuck: Can you use http://www.chromium.org/developers/bisect-builds-py to figure out when that happened?

In fact,this issue has never fixed, you can use test case in comment 5 and comment 23 to verify it.

ratsunny: It sounded like downchuck is seeing some kind of regression in m26.

Emm...I'm using chrome 26.0.1410.43 in beta channel.
Since M26 comes into beta channel, I didn't see any improve about this issue.

I my memory，I can only remember this issue not happen before M14(or other Milestone near M15),seems because gpu2d accelerated not enable by default and during M15 in dev channel it may have a one-version fix(may be a wrong disable accelerate), sorry I can't remember it's version number.

For a time, some hardware profiles had Canvas hardware acceleration disabled; they seem to have been re-enabled around M26. Once again, "Disable accelerated 2D canvas" fixed the issue.

As I said in comment 26
Now even I disable accelerated 2d canvas, it also had a noticeable latency.
But it's smaller than enabled. 

@39 It's now done in "about:flags" -- Which site are you noticing latency on? All latency disappears for me in my tests when I disable accelerated 2d Canvas. As verified on "about:gpu".

@downchuck
I am using extension "smooth gestures", you can add it to chrome and hold right draw a line to check.You will see the latency exist but smaller than accelerated.
Also, use SVG to draw line can cause noticeable latency.

Guessing that the smaller (but still noticeable) latency in recent versions is due to force compositing mode being enabled, so that software canvas is now gated on vsync.

Makes sense, there is a smaller latency. Does the owner/cc still need some kind of regression information? The simple test still exists in #5.

I haven't investigated this particular bug, but from the comments it sounds like Sami's patches for another bug might help:

https://code.google.com/p/chromium/issues/detail?id=161828#c108

The patches prevent gating on vsync if it's not required.

Is this issue going anywhere? Canary 29 is working a little better but the latency is still noticeable.

There are some general latency improvements being tracked in these issues: https://code.google.com/p/chromium/issues/detail?id=240945
https://code.google.com/p/chromium/issues/detail?id=168459

I looked at a quick trace of this app in particular though, and one thing that could be hurting performance/latency outside of Chrome itself is that the app triggers a glReadPixels. Reading pixels wouldn't be too bad in software mode, but results in a pipeline finish every frame in accelerated mode. Is there anyway you can remove the pixel reads?

The latency with current Chrome Stable (42) appears quite minimal. Lots has changed in the scheduling code since the bug was filed so I'm going to close this issue.