Jet Villegas:
> I've asked Cameron McCormack to look into how Firefox and other
> browsers should behave when under mild to severe stress. As all
> browser engines have to manage how to run under low memory, feeble
> network, pegged CPU, weak GPU, low battery, small/slow screens, etc.,
> I think web authors should know what to expect when their content is
> run on high-end machines and wristwatches. The hypothesis is that web
> authors will be frustrated by multiple browsers modifying their
> content for performance reasons without consistent/documented fallback
> scenarios. Cameron is initially focused on Web Rendering but we may
> want to specify what happens in other parts of the Platform as well,
> including the conditions that will trigger the graceful degradation of
> content.
>
> Some features that may have value as normative specs for all browsers:
>
> reduced or no antialiasing
> reduced color depth
> image downsampling
> image resizing/culling
> animation throttling (frame-rate reduction or frame dropping)
> reduced font/text feature usage
> audio/video bit-rate throttling
> content purging (how?)
> definition of browser stress levels (device profiles?)
I haven’t thought about the topic in much depth yet, so here are a bunch
of questions for everyone.
First I think we need to answer the question of what such functionality
would gain us. Two aspects come to mind:
1. Someone has a slow machine and visits a complex page that causes
responsiveness to be poor.
2. An author wants to write a page that performs well on a range
of devices with different performance characteristics.
For different browsers running on the same machine, some given content
might perform poorly or well, depending on how features are implemented.
In (1) we might want to reduce quality/correctness to make the
experience better for the user. If the user finds that content doesn’t
work performantly in Firefox, we might want to trade off quality/
correctness so that they don’t want to switch to another browser where
certain Web features are more performant. (Alternatively we might just
want to concentrate on closing the performance gap in that case. :-))
But if we do back off on quality/correctness, is this something that
should happen in a predictable way? If we detect that a page is having
performance problems (and exactly what that means might be something to
dive into, but assume for a moment we’re just looking at whether we’re
able to paint in time for the next frame) and that it is due, say, too
many box-shadows and SVG filters being used, should we have a defined
order of e.g. reducing SVG filter resolution, turning filters off, then
turning box-shadows off?
How coarse or fine grained should the change to these features be? How
standardised should this process be? Jet’s comment about authors being
frustrated that things degrade differently on different browsers sounds
right, or even more likely, that they won’t test on different browsers
resulting in pages being unusable in the untested browsers.
One other worry I would have is that the user might place different
value on quality/correctness and performance than we might. If they are
someone with an old computer who is used to things being slow, and we
make it so that pages degrade their use of complex features so that
performance becomes acceptable, might they prefer the original slow
experience?
PC games allow the user to turn certain features (mostly graphics
related ones) on and off so that they can find their own level of
acceptable performance/quality. This doesn’t seem like the right
approach for viewing Web content.
For (2), we might want to have a mechanism for the author to declare
whether a given feature is “important”, or to give a priority order to
features that the browser is allowed to reduce or turn off when it feels
it needs to.
One suggestion that was made at a recent SVG WG meeting where I brought
this topic up was to have a fixed, small number of performance levels
(high, medium, low) that the browser would decide it is in based on how
well the page is running. The page could then declare (with media
queries?) what to do in a given performance level, with the idea that
you’d turn off your box-shadows in low performance mode for example.
How many of these problems would go away anyway if we had APZC,
e10s, etc.?
There are a lot of open questions here so I’m interested in hearing
others’ thoughts.
--
Cameron McCormack ≝ http://mcc.id.au/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
