Visual glitches in left and right panel

In the smarter buffer resizing bug I found an issue that concave update regions were simplified by the TextureImage to their bounding box, while painting only occured inside the actually visible region. this lead to the layer contents being validated to the extents of the image, while only a small visible region was painted. subsequent painting events on exposed areas got lost since they were still valid. A similar issue resurfaced when using tiled texture images on top of smarter buffer resizing, which I am investigating now. --Heeen 05:55, 3 May 2011 (PDT)

GL_INVALID_FRAMEBUFFER_OPERATION errors on Maemo

The situation on maemo is that we use eglImage based Textures which can't be bound to the texture attachement poitn of a fbo, you need to use a rbo generated from the original eglImage.

Blitting

Blitting between images needs to be worked on when using the tiledtextureimage patch as we are no longer blitting one texture to the other but N:M textures. A huge improvement would be to do zero-copy blitting by using reasonable sized tiles and just reordering/recycling them.

Design changes needed

TextureImage changes

Right now TextureImage is little more than a wrapper for a opengl texture id. You get the id if you want to render it or if you want to attach it as a framebuffer target and do the rendering outside. There are problems with this if TI is to abstract away that we have limited texture sizes on GLES. You don't have one texture id anymore, but many, each covering a different part of the image. Right now I added iterating functions to the TI interface, so all users of TI can at least iterate over all sub-textures and work with that. Also, some textures can not be attached as a plain framebuffer texture, but have to be attached as a render buffer object through their underlying egl image. These combinations quickly make every interaction with TI very complicated.

Instead we should have texture images make more clever and integrate common usepatterns into them.

They should get a render function which automatically draws all tiles in a given rect or region with a given scale.

They should have an abstract BlitFrom or BlitTo interface in which they can decide on the method on how to get the data from one image to the other: software blit for eglImages that can't be bound to any fbo through egl lock or map, attachement as a fbo texture or renderbuffer target.

Another issue is component alpha, where we have a texture for color and another for alpha, multiplied by tiling. currently each tile binds both the texture for color and aplha and renders this tile with a given program. Maybe we also should abstract this into a multi-channel texture class. --Heeen 05:52, 3 May 2011 (PDT)

Patches

Here is a patch queue with work-in-progress towards the above issues. This should be applied on top of mozilla-central. You probably want to have a dedicated clone of mozilla-central for mobile development, and check this out as the .hg/patches subdirectory of it:

 http://hg.mozilla.org/users/florian.haenel_heeen.de/GLES_layers/