Hi, 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 web browser. 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[0], 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, for example. This is similar to Fennec, but doesn't involve the indirection that causes the performance issues in Fennec. --Chris [0] http://git.o-hand.com/cgit.cgi/webkit/tree/WebKit/clutter/webkit/webkitwebview.cpp#n2168 On Tue, 2010-03-23 at 13:53 +0800, Wu, Yong wrote: > Background: > 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. > > > Motivation: > 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 d oe > 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. > > > Solutions: > 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 > [email protected] > http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
