Closed Bug 737577 (the_jay_bug) Opened 8 years ago Closed 8 years ago

Excessive checkerboarding when double-tap zoom out

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 14
Tracking Status
blocking-fennec1.0 --- beta+

People

(Reporter: mfinkle, Assigned: kats)

References

(Blocks 1 open bug)

Details

(Whiteboard: [viewport])

Attachments

(1 file)

1. Go to nytimes.com
2. Double-tap to zoom into a column
3. Double-tap to zoom out

ER: Nice smooth transition to new zoom level
AR: Large amount of checkerboard around the central content. After a second or two the outer content will render.

Galaxy Nexus using Nightly.
blocking-fennec1.0: --- → ?
One thought I have about improving this is to start the draw of the zoomed-out content before the animation rather than waiting until the animation is done. It's tricky to implement though and may result in other visual weirdness.
Alias: the_jay_bug
Assignee: nobody → jmuizelaar
blocking-fennec1.0: ? → beta+
Assignee: jmuizelaar → bugmail.mozilla
Attached patch PatchSplinter Review
This reduces the checkerboard a little bit by requesting the content draw earlier. I'll need a test to actually measure the improvement though.
Attachment #609489 - Flags: review?(chrislord.net)
Comment on attachment 609489 [details] [diff] [review]
Patch

Review of attachment 609489 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, r+ with the two nits addressed.

::: mobile/android/base/gfx/GeckoLayerClient.java
@@ +174,2 @@
>  
> +        ViewportMetrics viewportMetrics = new ViewportMetrics(metrics);

nit, these variable names seem a bit arbitrary - perhaps 'immutableMetrics' and 'metrics' instead? Or 'metrics' and 'geckoMetrics'? They're both viewport metrics, so ommitting the 'viewport' on one seems a bit odd.

::: mobile/android/base/gfx/LayerController.java
@@ +269,5 @@
> +            // immediately request a draw of that area by setting the display port
> +            // accordingly. This way we should have the content pre-rendered by the
> +            // time the animation is done.
> +            ImmutableViewportMetrics metrics = new ImmutableViewportMetrics(viewport);
> +            DisplayPortMetrics dport = DisplayPortCalculator.calculate(metrics, null);

nit s/dport/displayPort/ ?
Attachment #609489 - Flags: review?(chrislord.net) → review+
OS: Windows 7 → Android
Hardware: x86_64 → ARM
Whiteboard: [viewport]
Duplicate of this bug: 737995
Landed with some renaming of variables as per Cwiiis' comments.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a9cc7ebe7598
Target Milestone: --- → Firefox 14
https://hg.mozilla.org/mozilla-central/rev/a9cc7ebe7598
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 741693
Duplicate bug has a couple of additional suggestion that could be broken out into more bugs.
I see this with any zoom-out gesture.  Is there something particular to double-tap zoom-out here?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #10)
> I see this with any zoom-out gesture.  Is there something particular to
> double-tap zoom-out here?

With the double-tap zoom-out, we know where we're going to end up so we can do better. With pinch-zooming, we have no idea where the user will end the pinch so we have to wait until they actually end it before we can trigger the final content draw.
Verified/fixed on:
Nightly Fennec 15.0a1 (2012-04-25)
Device: HTC Desire (Android 2.2.2)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.