450816 - Use a larger canvas for panning

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Panning/Zooming, defect)

Description

[Stuart Parmenter]

We should increase the size of our canvas to be larger than the visible area.

it would be great if it were floating, with default values such as:
3x height and maybe min(visible width, 150% * scroll width) (not sure if 50% width is enough, a good starting point, probably.)

So at (0,0) we might have something like:

----------------------------
|                          |
|                          |
|      visible area        |
|                          |
-------------------------------
|                             |
|                             |
|                             |
|                             |
|                             |
|                             |
|      hidden  area           |
|                             |
-------------------------------

or while scrolled:
---------------------------------
|                               |
|                               |
|        hidden  area           |
|                               |
---------------------------------
  |                          |
  |                          |
  |      visible area        |
  |                          |
---------------------------------
|                               |
|                               |
|        hidden  area           |
|                               |
---------------------------------

Comment 1

[Stuart Parmenter]

we should also benchmark if it is faster to paint all at once or paint in sections (visible first, hidden after)

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

This is a simple approach, with the canvas twice the height of the content area (50% above and 50% below the viewport).

Could use some extra testing, but seems to work OK.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

looks good at zoom=1, but has some problems when zoomed:
1. the initial double click to zoom doesn't redraw completely (pieces are left in view)
2. panning (mainly left and right) displays "junk" at the extremes

Both of these situations are cleaned up by the next redraw. In fact, #2 gets redrawn when the finger is lifted after the pan.

Comment 4

[Stuart Parmenter]

I'm seeing a number of odd things in addition to what finkle is seeing:  go to cnn.com and drag a small bit down and it often jumps nearly 50 pixels down.  i'm seeing a number of repainting problems as well, but not sure what is causing them...

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

I see the "jumps nearly 50 pixels down" issue too

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Attachment: better patch

This should solve all of the problems with the previous patch mentioned above.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 342472 [details] [diff] [review]
better patch

Tested out ok for me. I see none of the problems I saw with the first patch.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

http://hg.mozilla.org/mobile-browser/rev/3772037edcd8

some followup fodder:
-redraw hidden areas separately
-avoid redrawing the parts that don't change when ending a pan

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

verfied with beta3