Mobile/Layers: Difference between revisions
< Mobile
Jump to navigation
Jump to search
(→2.0 b1 TODO: multi-touch zoom) |
|||
| Line 8: | Line 8: | ||
=== 2.0 b1 TODO === | === 2.0 b1 TODO === | ||
* | * frontend | ||
** multitouch zoom is jittery | |||
** double clicking many times on desktop gives strange results | |||
** sometimes url bar comes up on double clicking a lot | |||
** (no bug) repeated taps on the scroll wheel (desktop) or volume rocker (maemo) cause incorrect zooming - a problem when a new event happens during an in-progress animation? | |||
* {{bug|585799}} band-aid for popup widgets in content processes | * {{bug|585799}} band-aid for popup widgets in content processes | ||
* shadow layer perf work | * shadow layer perf work | ||
** PROFILE MEASURE PROFILE | ** PROFILE MEASURE PROFILE | ||
| Line 24: | Line 27: | ||
* fix seaming, at least for simple cases (v. google.com @ 2.0 or 0.5 scale-zoom) | * fix seaming, at least for simple cases (v. google.com @ 2.0 or 0.5 scale-zoom) | ||
* daringfireball, pmo, and twitter all have some white regions at the top of the page | * daringfireball, pmo, and twitter all have some white regions at the top of the page | ||
=== 2.0 b1 nice-to-have === | === 2.0 b1 nice-to-have === | ||
Revision as of 19:14, 8 September 2010
See also Gecko:CrossProcessLayers.
Pre-Fennec work
- "shadow" layer trees (parent's reference to a child's tree) hooked into frame or widget code; currently they're only hooked into testing code. We need to associate TabChilds' shadow layer trees with their frames/widgets in the browser process.
- BasicThebesLayer pixel data shared efficiently with its BasicShadowThebesLayer (needed for realistic performance testing)
Fennec-specific work
2.0 b1 TODO
- frontend
- multitouch zoom is jittery
- double clicking many times on desktop gives strange results
- sometimes url bar comes up on double clicking a lot
- (no bug) repeated taps on the scroll wheel (desktop) or volume rocker (maemo) cause incorrect zooming - a problem when a new event happens during an in-progress animation?
- bug 585799 band-aid for popup widgets in content processes
- shadow layer perf work
- PROFILE MEASURE PROFILE
- (dougt/stuart) drawing scale-zoomed layers should not be slow
- bug 570625 draw ThebesLayer into X surfaces
- investigate using 16bpp for opaque surfaces on mobile platforms.
- bug 523172 non-sucky "basic" shmem backend for android, flush existing down the toilet
- (no bug) track updated region, only blit that from back --> front
- ... unless measurements says we mostly just update the entire surface, in which case swapping and always repainting would be better
- (no bug) smarter allocation of ThebesLayer backing buffers
- retained-content-only layer transactions
- bug 593243 invalidation of content outside the CSS viewport but inside the displayport is ignored
- fix seaming, at least for simple cases (v. google.com @ 2.0 or 0.5 scale-zoom)
- daringfireball, pmo, and twitter all have some white regions at the top of the page
2.0 b1 nice-to-have
- hacky slow fallback path for scrolling subframes (e.g. mobile gmail), only on pages with scrollable subframes
- bug 593310 draw a "checkerboard" or other indicator over waiting-to-be-filled regions
- (no bug) make CanvasLayer paint directly into shareable surfaces, remove third buffer
- don't draw the caret in the content process
2.0 musts
- compositing Basic*Layer tree published by content, using GL/EGL in the browser process
- HW-accelerated video that bypasses content-process main thread
- fast scrolling of subframes
- better support for position:fixed elements
- WebGL? proxied?
- fast plugin drawing? that bypasses content-process main thread?
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)?
- Where does double-tap to zoom live?
- Where does double-click simulation live? Nokia devices didn't support a native double click event. Maybe we still need to do some form of event re-dispatching to browser elements.
- Where does tap highlighting live? I think webkit has a tap-highlight-color CSS property.
Other questions
- What is the proper behavior for position: fixed elements when there is an additional displayport on top of the CSS viewport?
- what do other browsers with displayport-type things do?
- MicroB fixes wrt displaport, hides on pan, shows when pan finishes
- mobilesafari appears to basically ignore position:fixed wrt displayport
- what do other browsers with displayport-type things do?
Building
hg clone http://hg.mozilla.org/projects/cedar cd cedar hg clone http://hg.mozilla.org/users/bstover_mozilla.com/mobile2 mobile
From there, a normal opt or debug build will work.