Fennec native panning/zooming

[Christopher Lord]

Hi all,

One of the P1's we have for native Firefox Mobile is panning/zooming performance, and we still have some work left to do here.

These are the following bugs I'd consider important, relating to panning:

https://bugzilla.mozilla.org/show_bug.cgi?id=705092
Kinetic scrolling on web content is a bit too slow now (patch with r+, will push soon)

https://bugzilla.mozilla.org/show_bug.cgi?id=705358
Over scroll / scroll should not exist when page is fully zoomed out and all the content is in the view port. (patch with r+)

https://bugzilla.mozilla.org/show_bug.cgi?id=706146
Limit how far we can zoom into a page (patch with r+)

https://bugzilla.mozilla.org/show_bug.cgi?id=706489
Race conditions in viewport updates (patches with r+, but needs further work)

https://bugzilla.mozilla.org/show_bug.cgi?id=706891
Investigate making the axis lock unbreakable in some circumstances

https://bugzilla.mozilla.org/show_bug.cgi?id=708685
Main frame can pan when the iframe is being panned

https://bugzilla.mozilla.org/show_bug.cgi?id=708928
Don't render when a finger is down (patch with r+)

https://bugzilla.mozilla.org/show_bug.cgi?id=709120
There is often a perceptible delay when the screen is updated during panning (patch attached, WIP)

https://bugzilla.mozilla.org/show_bug.cgi?id=709152
There is excessive checkerboarding when panning, especially on single-core devices

Bugs #707965, #708349 and #708601 are also important, but I think are manifestations of bug #706489.

In my opinion, the critical bugs are jerking (bug #709120), the race conditions (bug #706489) and checkerboarding (bug #709152). kats, pcwalton and I (cwiiis) are working on these, but any help and feedback are appreciated.

James Wilcox (snorp) is working on a patch that allows us to use gralloc. Essentially, this gives us fast, asynchronous texture upload. This will really help our checkerboarding problems, but may not be a solution we can use on all devices.

I've been having a look at what we can do given the current constraints, and have had some initial positive results (patches are in my queue: http://hg.mozilla.org/users/chrislord.net_gmail.com/patches)

One idea I've been mulling over is whether it's worth writing a software layer renderer. Many of our problems appear to be down to limited memory bandwidth and stalling on copies. If we used a software layer renderer, we could avoid an extra copy and we can guarantee no over-draw in our rendering, so this may be something we should consider.

Comments welcome, hopefully I've not missed anything!

--Chris

[Jet Villegas]

> One idea I've been mulling over is whether it's worth writing a software layer renderer. Many of our problems appear to be down to limited memory bandwidth and stalling on copies. If we used a software layer renderer, we could avoid an extra copy and we can guarantee no over-draw in our rendering, so this may be something we should consider.

It sounds like you're exhausting #4 and #6 in the list of constraints we have, but you risk adding pressure to #1 and #2 with the proposed software renderer. You'll have to weigh the benefits with the additional cost. I'm curious why you overdraw in the GPU case, and how moving to CPU solves that bug. Could avoiding overdraw help your GPU memory bandwidth issues?

Limit 1: CPU ALU (arithmetic logic unit)
Limit 2: CPU memory bandwidth
Limit 3: GPU ALU (fragment shader math)
Limit 4: GPU TU (texture loads in shaders)
Limit 5: GPU VBO (vertex buffer uploads)
Limit 6: GPU memory bandwidth, total amount of pixels you touch per frame

_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

[Christopher Lord]

Ah, I didn't mean to imply that we're overdrawing with GPU rendering (we aren't, or at least, minimally), but that because we have a rendering path where we can guarantee almost zero overdraw, we're doing little more than shoving memory around. Because of this, we're not taking that much advantage of the GPU (though zooming will surely be better with GPU rendering, and we can shift to sub-pixel coordinates without much cost too).

What we would save is the extra copy from system memory to GPU memory (although really, this is just a memcpy I suppose, what with shared memory), but it is definitely a balancing act... I'd much rather we figure out ways of scheduling bandwidth usage better/using less of it, as ultimately we'll want to use the GPU for rendering; especially on devices with larger screens and if we switch to a tiled rendering scheme... But it might be something worth considering for the short term/certain devices.

--Chris