The "Canvas Performance Test" (http://www.smashcat.org/av/canvas_test/) exposes a bug on Windows (and WinCairo) rendering. If you view the website, and move the mouse while the animation plays, you will see that painting of the animation stops while the mouse is in motion. Once the mouse movement stops, the animation snaps to the proper state for the current time-slice. Interestingly, this problem does not appear when using CSS animation effects, or the requestAnimationFrame infrastructure. For example, this test does not show a problem: http://www.html5canvastutorials.com/demos/advanced/html5-canvas-linear-motion-animation/index.php
<rdar://problem/14989692>
This animation also does not exhibit the problem: http://jsfiddle.net/XQpzU/4358/light/
If I put printf statements at the point where I BitBlt, and at the start of the base WebView::paint method, the two are hit the same number of times. So we are not having a problem where the paint message is getting received, but we are not blitting to the screen. If I print a counter of each time these calls are hit, I stop seeing a counter update when the screen animation stops. This makes me think that the WM_PAINT messages are not getting generated for some reason.
This appears to be expected behavior. On Windows, user input always takes precedence over WM_TIMER and WM_PAINT messages. See http://support.microsoft.com/kb/96006?wa=wsignin1.0 for details.
One possible solution would be to make a call to webView->paint(0, 0); at the end of the mouse-move message handler. But this will cause the backing store to be blitted into the WebView more often than it would have been.
It looks like Chrome's generic HWND code schedules a repaint after every message is processed by the message loop: https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/win/hwnd_message_handler.cc&q=WM_PAINT&sq=package:chromium&l=923&dr=C And it looks like RenderWidgetHostViewWin repaints immediately every time new bits are received from the web process: https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/renderer_host/render_widget_host_view_win.cc&q=Redraw%5C(%5C)&sq=package:chromium&l=794&dr=C (It's definitely possible I'm misinterpreting some of this code.) I don't know whether or how Chrome avoids repainting the same region of the window multiple times within a single frame. But it certainly looks like they aren't just counting on WM_PAINT to be delivered reliably (since obviously you can't).
Created attachment 211830 [details] Patch
Committed r155901: <http://trac.webkit.org/changeset/155901>