Closed Bug 729391 Opened 8 years ago Closed 8 years ago
Maple checker-boarding tracking bug
No description provided.
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.
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.
(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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: checkerboarding
You need to log in before you can comment on or make changes to this bug.