Closed Bug 1049673 Opened 10 years ago Closed 8 years ago

[meta] FirefoxOS graphics multiple tiered devices support

Categories

(Core :: Graphics, defect)

26 Branch
x86
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
tracking-b2g +

People

(Reporter: milan, Unassigned)

References

(Depends on 1 open bug)

Details

We have a number of places where we trade off memory for performance, usability for size, etc.  For example, bug 1002430 would have us not release some memory that we have to release on lower memory devices.  Or the conversation about 3 vs. 4 icons in the homescreen, perhaps tuned to different devices.  Or the hack we have for limiting Skia GL cache size on "low" memory devices to 2mb, while otherwise giving it 1/16th of the available memory.

This is a meta bug to track the decision to actually do this, get the product input on the importance of it and link different bugs to it so that we can track it.
blocking-b2g: --- → backlog
Depends on: 1002430
My initial thought is to focus on 2 tiers of 128M devices and 256+ devices, the latter being the miminum that we support for most "common" (needs clear definition) configurations. 

There will be some exceptions that we add on top of the "common" configuration that certain device specific BOM items would need e.g. screen resolutions, camera resolutions/features such as HDR etc. Those would need to be called out "per line item". 

Thoughts?
One option is what you suggest - low and normal.  256mb is actually starting to be low as we're adding more features and for different types of apps, we'd probably be looking at 512mb+, or maybe even higher (partners are probably a good source of this info.)
The other option is to go with three tiers - low, normal and high.  So, in low you really tighten things down, at the expense of performance (e.g., scroll will checkerboard more often, we would turn off accelerated canvas completely, so games would not run well) and in high you throw memory at problems to really get good performance (e.g., you never do low res tiling and you still don't checkerboard, we crank up accelerated canvas cache, etc.)  It is also tempting to try and make this into a sliding scale, where everything just gradually shifts, but I'm not sure if that can be done in general.
Agreed, there will be several market configurations for various price/spec tiers and regions. Every product would have it's own reasons and trade-offs for what works for them best. Some tiers (and markets if price is "right") do accept HW performance at the levels what developed markets would frown upon.

To elaborate further, I think Mozilla could have a couple "suggested memory configurations" (I still prefer 2 vs 3 just for simplicity). Based on those, We could enable OEM partners create the recipe for their products based on their specs/needs. The suggested memory configurations for low-tier (128M)products would be a guideline for what works best for that general tier, beyond which there will be trade offs. similar for 256+ tier. 

e.g. If a specific partner wants to have a FWVGA device with 5MP HDR camera on a proposed 256MB device, they would be able to make those necessary modifications to the suggested configurations (as in ensure more RAM is available to account for those items, or take a hit for some performance).  

This may be a bit more complex than this (still manageable) but just my directional thinking if that makes sense.
add tracking flag for backlog.
tracking-b2g: --- → +
blocking-b2g: backlog → ---
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.