Summary: | [EFL] Tiled Backing Store for Webkit-Efl | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alex Bredariol Grilo <abgrilo> | ||||||||
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | abgrilo, antognolli+webkit, barbieri, commit-queue, gyuyoung.kim, joone, jprvita, kenneth, koivisto, leandro, mrobinson, ryuan.choi, tonikitoo | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Other | ||||||||||
OS: | OS X 10.5 | ||||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 45777 | ||||||||||
Attachments: |
|
Description
Alex Bredariol Grilo
2010-09-08 09:51:31 PDT
Created attachment 67450 [details]
Patch
Other bugs will be create for changes in WebCore, WebcoreSupport and EWebLauncher and then Tiled Backing Store will be working. Why is this better than building on the tiling stuff in WebCore? In what ways is in better? Hi Kenneth, As the one that designed it, I can join with possible insightful comments. Unlike the code that were introduced by Qt, this one operates outside WebCore and as the benefit it does support all the features a regular page would need: iframes, frames and other nasty bits that in other would require frames to be flattened. In theory, if Evas was a bit more clever, we could do this in a transparent way... seems that Apple guys do this with their GraphicsCore, but I cannot say for sure. The current code is quite simple: instead of rendering to a single image buffer that is later displayed, it does in a matrix of image buffers. The current implementation have all tiles to be proportional of the base-size at zoom 1.0, that is if we consider a base-size of 128x128, at zoom 2.0 it would be 256x256 and thus regions map perfectly and tiles from different zoom levels can be scaled to fit as placeholders while tiles render. Of course this provides some drawbacks, like very small zoom levels will produce lots of small objects, and very large will produce huge memory blobs, but it is serving us quite well (however in future we may provide alternative implementation with a different approach). The other benefits remains the same: if you scroll you don't have to memmove regions inside the buffer, instead just ask the rendering system (evas or qt) to paint it at another position... with OpenGL you keep textures intact and avoid re-upload, etc. I hope this is enough for upstream of these patches. If not let me know! Just a few comments before I'm heading to bed... (In reply to comment #4) > Unlike the code that were introduced by Qt, this one operates outside WebCore and as the benefit it does support all the features a regular page would need: iframes, frames and other nasty bits that in other would require frames to be flattened. In theory, if Evas was a bit more clever, we could do this in a transparent way... seems that Apple guys do this with their GraphicsCore, but I cannot say for sure. The frame flattening is not actually due to the tiling, but more due to the touch interaction model where we do not want separate sub areas to scroll separately depending on where you pan. > The other benefits remains the same: if you scroll you don't have to memmove regions inside the buffer, instead just ask the rendering system (evas or qt) to paint it at another position... with OpenGL you keep textures intact and avoid re-upload, etc. I believe there is nothing in the WebCore tiling implementation not making this possible. Maybe Antti can give some comments. Bugs 45750 and 45773 also adds changes on WebCore API needed for the tiled backing store fully work. Hi Kenneth, Your tiled backing store seems to provide the basic functionality that we need, but some of them are not covered (and I'm not sure it makes sense to add them to WebCore's TiledBackingStore. For example, we need some operations to scale and move tiles for zoom (our weak zoom function) that doesn't seem easy to me to implement using the tiling model in WebCore. Another point is our pre-rendering, and it seems to me not trivial to request WebCore to render more tiles that are not rendered or even close to the viewport yet. We allow this through an API that lets the client (browser) to decide when to pre-render these tiles, and which tiles should be pre-rendered. We also cache the repaint and scroll operations until we really need to apply them (on one ecore main loop iteration). This is similar to what you do in your Tile::invalidate method, but instead of a timer we wait for Ecore and Evas to decide when to call the paint callbacks. And we also don't drop tiles away when we are scrolling, but instead we keep them in a cache for being used later, and the cache decides when to drop the tiles. This is our policy to dropping tiles based on the memory constraint set by the client/browser. I believe that these and other kind of fine control over what happens to our tiles are possible to be implemented with your tiled backing store, but by the time of implementation we concluded that the design would become too complicated to enable that. Since this code wasn't available/public yet, we couldn't discuss these changes that we needed on your backing store. I think now it's possible to do that, but we also would like to have our backing store upstreamed (since we have some good work on that). I also think that we can later implement a tiled backing store using your tiling infrastructure, and maybe start upgrading it to allow these kind of features that we have, but now I think it's too early for that. Created attachment 71305 [details]
Patch
Comment on attachment 71305 [details]
Patch
As all this code is relevant for EFL only and isolated, I see no reason why it cannot go in.
The code has been looked over by EFL experts so r=me.
Created attachment 74552 [details]
Patch
Comment on attachment 74552 [details] Patch Clearing flags on attachment: 74552 Committed r72579: <http://trac.webkit.org/changeset/72579> All patches have landed, closing bug. |