792138 - Reduce the displayport size on low-memory devices

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

The java code has a few different displayport strategies; currently the default causes the displayport (area drawn by Gecko) to be larger than the visible area, so that asynchronous panning/zooming doesn't result in checkerboarding as quickly. However this requires more memory. We should try switching strategies to have a smaller displayport.

This can be easily tested by setting the pref gfx.displayport.strategy=3 but we'll need to figure out when to enable this (if it should be done dynamically or not, and under what conditions).

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Whoops, submitted before I finished editing the summary.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

Looked into this briefly. On this HTC Wildfire, we currently produce a displayport that is 768x1024. With the no-margin strategy, this changes to 320x407. The buffer size ends up being about a meg smaller, and the performance is of course noticeably worse. Besides the buffer being smaller, I'm not yet sure if we save much memory during the rendering process. I'm not convinced it's a worthwhile trade at this point because the performance is so much worse.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Hmm. I wonder if BenWa's tiling cache changes will improve things enough in this case to make it worth it.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Was talking to BenWa about this today. We now have two displayports, the high-res one and the low-res one. We can probably shrink one or both of these on low-mem platforms to reduce memory usage. See also bug 818169.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Are we still interested in reducing the displayport on low-memory devices? Are there a significant number of low-end devices that would benefit from this?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #5)
> Are we still interested in reducing the displayport on low-memory devices?
> Are there a significant number of low-end devices that would benefit from
> this?

I don't have a good answer about the number of low-end devices. I have heard that hardware should be improving on *low-cost* devices. That might mean we are moving out of the low-memory era, but I did just buy a $70 Android phone running 4.2 and dual cores but with only 256MB of RAM. No idea why they went cheap on the RAM.

I'll ask the Mozilla insights team about the low-memory situation and get back to you.

Comment 7

[Chris Lord [:cwiiis]]

Probably not the right place to comment, but I will anyway - are we bothering with APZC/tiles/displayports on very low-memory devices? With 128mb or less, it makes a lot more sense to me to just use synchronous, non-tiled rendering - we'd save a lot of memory doing so...

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(In reply to Chris Lord [:cwiiis] from comment #7)
> Probably not the right place to comment, but I will anyway - are we
> bothering with APZC/tiles/displayports on very low-memory devices? With
> 128mb or less, it makes a lot more sense to me to just use synchronous,
> non-tiled rendering - we'd save a lot of memory doing so...

I think at this point we're pretty much committed to OMTC (and therefore some APZ variant) on all platforms. We can turn off tiling if that will reduce memory usage.

Comment 9

[Chris Lord [:cwiiis]]

Yes, I think that would be a good idea - and perhaps a screen-sized displayport (or very near screen-sized) with the no-checkerboarding heuristic and bug 968505 fixed.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Given that we're dropping support for ARMv6 and there hasn't been any movement here I'm going to close this. Reopen if there is any decisions are made that require action here.