Mobile/Layers
< Mobile
Jump to navigation
Jump to search
Pre-Fennec work
- "shadow" layer trees (parent's reference to a child's tree) hooked into widget/ code; currently they're only hooked into testing code. We need to associate TabChilds' shadow layer trees with their widgets in the browser process.
- BasicThebesLayer pixel data shared efficiently with its BasicShadowThebesLayer
Fennec-specific work
- remove TileManager.js entirely
- replace tile management with roc's new BasicThebesLayer: in the content process, allocate a layer with a visible region larger than the content area, so as to automatically "prefetch" content
- (intermediate step) move TileManager.js into the content process, add gfx/layers hacks for drawing "checkerboard" over waiting-to-be-filled regions
- What does move TileManager.js into the content process mean? I thought we were removing it entirely. -Ben
- make tile management a first-class Layers API, perhaps through a TiledLayer or somesuch
- support GL/EGL compositing in the browser process of a Basic*Layer tree published by content
- (pie in the sky) investigate sharing GL/EGL resources between browser/content, that is, cross-process GL/EGL layer trees
- Need to make sure <browser> keyboard events will be forwarded properly
Questions that come with using browser element
- Where does panning and kinetic panning live?
- Ben: hopefully as javascript in browser binding
- Where will handling of zoom metadata live?
- Where will the tap => element code live (including better link clicking and transforming coordinates for zoom level)?
- Ben: hopefully as javascript in browser binding
- Where does double-tap to zoom live?
Other questions
- What is the proper behavior for position: fixed elements when there are two viewports involved (what the user sees and what the virtual viewport for layout is)?