[MeeGo-dev] The nativer rendering model proposal in Fennec
chris at linux.intel.com
Tue Mar 23 05:35:38 CDT 2010
Apologies for top-posting - I wanted to keep the original mail here, but
I'm digressing slightly from it.
What I think you want in this situation is what I wanted to get to (but
didn't get round to, what with the project cancellation) in the moblin
You can achieve fast, native panning by disabling the clipping on
scroll-areas, disabling scrollbar chrome and using a sliding-window for
buffering areas outside of the visible viewport. I used this method in
webkit-clutter, and had plans for this in clutter-mozembed. Note that
webkit-clutter almost certainly doesn't compile now and it's old code,
I'm just linking to it to demonstrate what I mean.
The benefits of this are that you can still use the native rendering,
plugins will still work, etc., but you massively reduce load as you
don't constantly re-render whenever the viewport origin changes by a
single pixel. I'm convinced that this is how the iPhone renders pages,
This is similar to Fennec, but doesn't involve the indirection that
causes the performance issues in Fennec.
On Tue, 2010-03-23 at 13:53 +0800, Wu, Yong wrote:
> Fennec uses a different rendering model as Firefox, to support multiple touch and better panning/scrolling performance/experience. In Fennec browser, the rendering engine can not paint directly to X window. Instead, it introduced a new layer called tile manager based on html5 canvas. Everything are copied/converted from the browser content window to the tiles and to show up on the display.
> The tile based rendering model has several drawbacks:
> 1, Poor Flash Performance.
> Windowed plugins (including most of flash plugins) are not supported directly. Since windowed plugins are painted to X window by its internal event loop, browser has no way to catch the rendering result and repaint it on the tiles. To support the windowed flash, we forced all the windowed plugins to be opaque windowless. Windowless mode is supported because in that case plugin will paint to a drawable provided by browsers. And each repaint will trigger an invalidation event to browser. But this will cause serious performance issue - not only due to windowless plugins eat more CPU cycles, but also because of each expose event will cause a surface copy to tile cache. As a the result, the play speed is normally less than 10 FPS. Nokia ever proposed a new rendering model based on shared memory for plugins. But unfortunately, it needs code changes to flash plugins to support the Nokia specific NPAPI extension. And, that new NPAPI extension and the shared memory rendering model doe
> s *not* support the coming OOPP (out of process plugin) feature in Gecko engine.
> 2, Java/PDF/Silverlight and other plugins does not work.
> The tile based rendering model can support only XEmbed windowless plugins. The PDF plugins, runs in XtBin mode and Java plugins, which can run in XEmbed mode but does not support windowless feature, thus neither of them works in Fennec.
> 3, Panning/scrolling issue for websites need inter-element scrolling
> Web applications like Google map does not work. Since the mouse panning actions will be caught by the browser view and can not reach the Google map content window. Actually, in Fennec, you will have troubles to input a long text from any text area forms. Since you will have no chance to move the scroll bar of the text area. Fennec will panning the whole browser view always.
> We introduced the native rendering mode to Fennec. Basically the native rendering is to draw directly to X window as what Firefox do. It is pointed to avoid the tile manager conditionally. We will let both mode (native rendering & tile rendering) co-exist for Fennec.
> 1, By default browser will enter tile rendering mode. Each tab can either be native rendering or tile rendering mode. At every time, browser can show only one tab content thus browser will enter native rendering when the selected tab is under native rendering.
> 2, We provided mechanism to switch between tile rendering and native rendering. Such transition is basically free: It does not change the page layout. There is no need to trigger any repaint events from the rendering engine. It does not change the user status (loggined, text inputing, etc..).
> 3, We have limited support for panning In native rendering mode. We enabled panning to access the tabs/history/preference bars. But, to view web content, user need to use the scrollbars, or page built-in mechanism, like Firefox. This is to fix the Google maps and text area inputting issues.
> 4, Plugins are supported in a better way. Firstly, Java/PDF plugins will be supported. Secondly, we can have the best flash play performance without changing the flash plugin code. And finally, it is OOPP friendly.
> 5, We enter the native rendering in the following four scenarios: a) automatically enter native rendering for any full-screen objects, for instance PDF or full screen video display. b) automatically enter native rendering when the dominant viewport of user content view is a plugin window, esp, user are watching a flash video. c) suggest to enter native rendering mode when there is embedded Java/flash plugins. This will enable Java plugins and improve flash performance. d) at any time, user could choose to enter/leave native rendering manually (via a toolbar button).
> Main concerns:
> 1, In native rendering mode, the panning/scrolling experience is different from the tile rendering. And considering the scrolling performance, it is slower than in tile rendering - due do the continuous reflowing/redrawing. In the tile rendering mode, it simply avoids the redrawing by the tiled cache.
> 2, To the end user, the native rendering concept, and suggestion for users to enter a native rendering mode can be confusing.
> Any comments? Please!
> MeeGo-dev mailing list
> MeeGo-dev at meego.com
More information about the MeeGo-dev