> Safari must also be using something like IOSurfaces to make pixel data available across
> processes, so I'm guessing similar performance must be achievable in Chrome.

Safari uses private SPI to share surfaces, which has different behaviors than IOSurface, so things that Safari can do aren't necessarily feasible in other browsers (which is why Invalidate Core Animation exists in the first place).

kbr, thakis, any thoughts? How is the GPU process handling this?

(I think Safari uses CARemoteLayerClient / CARemoteLayerServer which as of 10.7 is no longer SPI. But we can't use it because we don't use CA in the renderer, and that's because our sandbox is more strict than Safari's amongst other reasons.)

Neither end of NPAPI drawing is in the renderer, so if this exists (undocumented) in 10.6 we could presumably use it. But did it really, or is that a 10.7 formalization/replacement of whatever internal thing they used in 10.6?

Currently, theoretically, if we could share a Core Animation layer tree across processes, then we could use that mechanism to render CA plugins. The plugin vends a CA layer to the plugin process, and the plugin process would share that layer with the browser process for display onscreen. Currently Chromium uses a CARenderer in the plugin process to render the plugin's output into an IOSurface, and that IOSurface is drawn to the screen using OpenGL in the browser process.

However, this is all changing in  Issue 38967 , where CA plugins will be drawn to the screen using the compositor. Given that this will be a major change, further investigation into this issue (or any advice) should be deferred until those changes are in.

Under the new code path there would not be much point in sharing the layer tree across processes. Chromium's compositor implementation, unlike WebKit's, does not use Core Animation, so it could not import the plugin's layer into its layer tree.

To determine how quickly to render, pure HTML5 web applications use requestAnimationFrame. Perhaps it would be possible to drive your plugin's animation loop using that plus scriptability of your plugin.

Note that there are reports that http://box2dflash.sourceforge.net/ drops frames while the plugin thinks it is rendering at 30-60 FPS. This may be the same underlying issue. I'm hoping the behavior improves with the new rendering path for CA plugins.

The box2dflash problem sounds exactly like what we are seeing.

I'll check out the use of requestAnimationFrame and wait for the compositor.

Thanks for the information.

Just wanted to update after trying the requestAnimationFrame suggestion, in case other people are in a similar situation.

Using requestAnimationFrame to drive the framerate allows events from the browser to arrive at the plugin much quicker (previously when the system was under load we would sometimes see a perceptible lag between keys being pressed and events reaching the plugin), however it only has a marginal effect on the issue of frames being dropped.

(Not sure if it's of any help but there was a more noticeable improvement under Firefox 8, both in terms of frames being skipped and events reaching the plugin.)

The fix for  Issue 38967  (rendering Core Animation plugins through the compositor) has landed. Unfortunately it doesn't appear that it has magically solved the problem. I think that the behavior with box2dflash looks a little better, but the improvement, if any, is definitely incremental.

It's certainly technically possible for the entire browser window to update at a solid 60 FPS, so there must be some solution. Perhaps we need frame rate throttling between the plugin and GPU process, to avoid overloading the GPU with more frames than can be rendered.

Closing due to NPAPI deprecation.