607777 - Make a good metric for checkerboarding

Status: RESOLVED WONTFIX

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

Description

[Benjamin Stover (:stechz)]

My first thought is: maximum pixels / sec that we can pan without seeing a checkerboard. This could be completely automated.

Comment 1

[Benjamin Stover (:stechz)]

A good first step would be a small extension that allow us to set scroll velocity so we can see for ourselves.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

In some more detail, the idea is, write an extension that automatically scrolls content (by dispatching touch events, to go through the "normal" code paths) at a controlled, configurable velocity (in the vector sense).  To test patches, a dev could load a page, set the velocity to X, then see "hm yes, no checkerboarding."  Next the dev might set it to 5X, and retest; that might cause visible checkerboarding.  Then the dev might set the velocity to 2X and retest, and repeat.  From that we could get a hand-wavy informal measure of maximum scrolling speed without checkerboarding.

The project I have to do this sort of measurement automatically has basically no chance of making 4.0, so we probably will want some hacks like this one.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

It might be possible to use information provided by nsIView to mechanize some of the hand-waving, but I've been out of that code for a while.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

... by which I meant nsIContentView.

Comment 5

[Matt Brubeck (:mbrubeck)]

This work might benefit from the "MozDisplayportChanged" event/notification proposed in bug 649041.

Comment 6

[Wesley Johnston (:wesj)]

Attachment: WIP Patch

I've been looking at this with stechz's help a bit. First plan of attack was just to expose the current display port to js, and then can check during panning if the visible area is entirely inside the current displayport.

This patch should expose the displayPort, but the units seem off. Putting this up for any feedback from stechz or someone else who knows their way through this code.

Comment 7

[Wesley Johnston (:wesj)]

Attachment: Extension

This is a quick WIP extension to pan the page at different rates and measure the amount of checkerboard*time shown. Panning works, but the measurements are wrong...

Comment 8

[Benjamin Stover (:stechz)]

Comment on attachment 555541 [details] [diff] [review]
WIP Patch

This works well for me. All I have is nits: don't shorten DisplayPortRect to DispPortRect, wrap lines properly. You will need to bump IID.

Something to note in your addon: the displayport we set can be any size we want and can be actually bigger than the entire content document. We clip this appropriately for rendering, but this property will reflect the unclipped value. Typically in Fennec this just means that your displayport is bigger than your content document so I doubt this will cause you to run into any problems in your extension.

Comment 9

[Benjamin Stover (:stechz)]

Also: great work! This is sorely needed. Thanks for stepping up.

Comment 10

[Wesley Johnston (:wesj)]

Sorry, I am swamped right now and haven't had a lot of time to finish this up. Wanted to list info from my last conversation with stechz about this so that its at least documented. If someone else wants to grab and run with this, feel free.

The extension currently pans the current page at a few different rates by calling MainDragger.dragBy(dx,dy) repeatedly. My initial thought was just to computer the displayportrect and the visible rect at each frame. If the visible rect was outside the displayport rect, we'd jot down how much are was not yet rendered (checkerboard) for this amount of time (dA*dt). I was also jotting down the framerate because... well I thought it might be nice. And at the end showing the total checkerboardArea*secs shown.

For real me and stechz talked about panning at a particular rate, say 10px/sec, and watching to see if there was any checkerboarding. Rather than panning using the dragger, it would be best to pan by throwing mouse events at the window, so that we hit the entire panning path that we see on devices. If we made it to the bottom of the page without seeing any checkerboard, we'd restart at a faster rate. If we did see some, we'd throttle back the rate until we found some maximum pixels/sec we could pan without checkerboarding. That way we have a single number that describes panning in this situation. For real tests we could design a set of pages with varying degree of difficulty rendering. Right now I was just using planet because its long and fairly complex. Apply patches/tweak prefs + repeat!

Initially I wondered if it was ok for us to show a lot of checkerboard if we only showed it for a very short time. Still not sure that is answered here.

Comment 11

[BMO Automation]

Closing all opened bug in a graveyard component