Bug 45397

Summary: [EFL] Tiled Backing Store for Webkit-Efl
Product: WebKit Reporter: Alex Bredariol Grilo <abgrilo>
Component: New BugsAssignee: 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 Flags
Patch
none
Patch
none
Patch none

Description Alex Bredariol Grilo 2010-09-08 09:51:31 PDT
[EFL] Tiled Backing Store for Webkit-Efl
Comment 1 Alex Bredariol Grilo 2010-09-13 12:17:27 PDT
Created attachment 67450 [details]
Patch
Comment 2 Alex Bredariol Grilo 2010-09-13 12:24:13 PDT
Other bugs will be create for changes in WebCore, WebcoreSupport and EWebLauncher and then Tiled Backing Store will be working.
Comment 3 Kenneth Rohde Christiansen 2010-09-13 13:56:55 PDT
Why is this better than building on the tiling stuff in WebCore? In what ways is in better?
Comment 4 Gustavo Sverzut Barbieri 2010-09-13 14:12:30 PDT
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!
Comment 5 Kenneth Rohde Christiansen 2010-09-13 14:19:32 PDT
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.
Comment 6 João Paulo Rechi Vita 2010-09-14 13:17:20 PDT
Bugs 45750 and 45773 also adds changes on WebCore API needed for the tiled backing store fully work.
Comment 7 Rafael Antognolli 2010-09-21 13:35:18 PDT
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.
Comment 8 Alex Bredariol Grilo 2010-10-20 10:27:46 PDT
Created attachment 71305 [details]
Patch
Comment 9 Kenneth Rohde Christiansen 2010-11-17 13:07:02 PST
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.
Comment 10 Alex Bredariol Grilo 2010-11-22 07:37:58 PST
Created attachment 74552 [details]
Patch
Comment 11 WebKit Commit Bot 2010-11-22 18:35:22 PST
Comment on attachment 74552 [details]
Patch

Clearing flags on attachment: 74552

Committed r72579: <http://trac.webkit.org/changeset/72579>
Comment 12 Leandro Pereira 2010-11-23 07:24:56 PST
All patches have landed, closing bug.