Closed Bug 729391 Opened 8 years ago Closed 8 years ago

Maple checker-boarding tracking bug

Categories

(Core :: Graphics, defect, P1)

x86
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 717774

People

(Reporter: jrmuizel, Assigned: jrmuizel)

References

(Depends on 3 open bugs, Blocks 1 open bug)

Details

(Keywords: meta, Whiteboard: MAPLE mwc-demo)

No description provided.
Whiteboard: maple
So far we don't have any leads on what we need to do to make this better. Benoit Girard and I will be investigating this in more depth tomorrow.
Assignee: nobody → jmuizelaar
Summary: Maple checkboarding tracking bug → Maple checker-boarding tracking bug
Just a note about any comments I make, my test device is an HTC Flyer - this is a single-core 1.5ghz, Adreno device with a screen resolution of 1024x600. I consider its performance to be that of a mid-range phone.

I think the checkerboarding and slowness is a combination of a few things:

1- We don't have any texture-from-pixmap style extension. This means that all our uploads happen synchronously when rendering. snorp/pcwalton were working on getting us gralloc here, which would help immensely.

2- We have *huuuge* buffers - I'm not sure where the size is coming from (the displayport set on buffers is only 300 pixels around the screen size). This means that we often deal with uploads in the region of 2000+ pixels (even on a 1024x600 screen), for no real reason. No area of the page outside of the 300 pixel buffer set in the displayport is rendered.

3- Buffer rotation doesn't appear to be working. At least on Engadget, I'm constantly seeing huge uploads when scrolling a small amount.

4- Even when scrolling without uploads happening, our basic draw loop seems to be doing too much work. You can show this by scrolling only in over-scroll (which won't trigger any redrawing) - the frame rate I get hovers around 30.

I've not looked deeply into any of these, I've just been tracing through the code to find out what's going on so far, but I think fixing any one of the first three will have a significant impact on both general performance and checkerboarding in particular.
Depends on: 729534
Depends on: 729538, 729537
After further testing, 2 and 3 aren't exactly right.

On my 1024x600 device, I have a 600x950 viewport in portrait orientation. We have a constant in browser.js that determines the size of the buffer area on each size of the displayport - this is currently 300.

- On startup, after going to engadget, the backing buffer size of the Thebes layer that makes up most of the page content is 1020x2532.

This is bad - 1020 is greater than the page width at the zoom level that it starts off in, and 2532 is larger than 950 + 600 - the largest size the displayport should be able to stretch to.

- After pinch-zooming, the backing buffer is restored to a normal size. It tends to exceed the maximum size by a pixel or two, I assume due to rounding issues.

- When scrolling around on engadget, a lot of updates tend to update the entire back buffer. This would indicate that rotation isn't working correctly. Going to m.wired.com, you see rotation working better, but still quite often see the entire back buffer uploaded at once after scrolling only a small amount.


There are definitely issues to work out here.
Whiteboard: maple → MAPLE mwc-demo
(In reply to Chris Lord [:cwiiis] from comment #3)
> - On startup, after going to engadget, the backing buffer size of the Thebes
> layer that makes up most of the page content is 1020x2532.
> 
> This is bad - 1020 is greater than the page width at the zoom level that it
> starts off in, and 2532 is larger than 950 + 600 - the largest size the
> displayport should be able to stretch to.

I think a lot of this is the displayport code not scaling properly. This may be a simple fix.
(In reply to Patrick Walton (:pcwalton) from comment #4)
> I think a lot of this is the displayport code not scaling properly. This may
> be a simple fix.

To clarify: The displayport is in CSS pixels, not actual rendered pixels. That is, the current Thebes layer resolution as set by SetResolution() is not taken to account. So it must always be scaled by the zoom.
Depends on: 729653
Depends on: 718388
Priority: -- → P1
Depends on: 729975
Depends on: 730967
Depends on: 727352
Depends on: 731603
Depends on: 733941
Depends on: 735303
Depends on: 733607
Depends on: 735893
Depends on: 735895
Depends on: 735898
Depends on: 737450
Depends on: 737510
Depends on: 733041
No longer depends on: 737510
Depends on: 737510
Depends on: 737553
Depends on: 737634
Depends on: 737686
Depends on: 739679
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: checkerboarding
Depends on: 742115
Depends on: 742600
No longer depends on: 742600
You need to log in before you can comment on or make changes to this bug.