<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 18/05/2014 08:38, L. David Baron
wrote:<br>
</div>
<blockquote cite="mid:20140518073838.GA12893@crum.dbaron.org"
type="cite">
<pre wrap="">On Saturday 2014-05-17 23:53 -0700, Matthew N. wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We are continually working around platform bugs since we can't always get proper fixes prioritized (even when they are blocking a big project like Australis e.g. various performance issues that blocked the Nightly landing for months). What is the channel to try and get proper platform fixes prioritized? e.g. getting it on the goal list for another team. I don't think this is the fault of any individual developers, more that other teams have different priorities which are not as clear compared to having something like the backlog. Does this fall under the responsibility of Product/Project managers?
</pre>
</blockquote>
<pre wrap="">
I think there are other ways of looking at this problem, though.
Some of the fixes that were blocking Australis that I was aware of
were things like the SVG image caching work and clip-path
optimization work that Seth was doing. These were projects that
involved weeks of work themselves, so they weren't at all trivial,
and they were prioritized pretty highly once we became aware of the
need for them.</pre>
</blockquote>
I think Matt isn't saying "the platform team is too slow doing the
stuff we want". I think Matt is (primarily, right now) saying that
"not granting firefox-backlog and otherwise doing nothing with these
bugs means that the platform team either doesn't know we think it's
important, or worse, decides it probably isn't important (because
why fx-bl- otherwise?) - what are we doing instead/additionally to
communicate our priorities?"<br>
<br>
<blockquote cite="mid:20140518073838.GA12893@crum.dbaron.org"
type="cite">
<pre wrap="">Taking a step back, though, I think part of an engineer's job is to
understand the performance characteristics of the features that
you're planning to depend on. It's far better to talk to platform
folks about how a feature performs (and perhaps also measure its
performance in an appropriate way) before building a lot of code
that depends on it, and probably even before committing to UI
*designs* that depend on it.</pre>
</blockquote>
I take issue with some points here.<br>
<br>
One, that we don't talk to the platform team, or don't measure, or
don't think, about perf characteristics of solutions we choose. The
story of tabs (intimately connected with the SVG caching you
highlighted earlier) on which Matt, Jared and Mike measured and
slaved away for a really long time, all the while being helped by
gfx and layout folks, says otherwise.<br>
<br>
Two, that we can always do the perf measurement/talking in the
abstract, and that it is effective that way, without "committing to
UI designs" that depend on us having a sane way to implement. It
turns out that browser.xul is pretty complicated these days, and a
bunch of the perf things we found for tabs certainly wouldn't have
come up in an "abstract" discussion/testcase with just the new tab
shapes (e.g. the semitransparent glass background, glass fog, the
overlap/underlap of the tabbar with the navbar and its impact on
perf, OS theme changes while Firefox is running, etc.)<br>
<br>
Three, that we as engineers have a job to be the "destroyers of
ideas" in terms of UI ideas which are, in theory or in practice, not
trivial to implement. Two random examples: we'd like a version of
text-overflow (or xul crop) that works on a paragraph/block basis
rather than line by line (or a single line) and we'd like a way to
fade out single-line text on an arbitrary unknown background (!),
instead of ellipsoiding it. Both of these are (to the best of my
knowledge, having talked to various platform people) things which
are either impossible or very hard with the current featureset of
gecko. Both of them could be solved in a much more performant way by
adding platform features. Both of them would strictly improve the UI
look as well as utility (seeing more actual characters > seeing
ellipses; knowing text is cut off > not knowing text is cut off).
We've not implemented these, but we sure would like to. Hence:
platform bugs to get features added that will let us do those
things.<br>
<br>
<blockquote cite="mid:20140518073838.GA12893@crum.dbaron.org"
type="cite">
<pre wrap=""> Some features are inherently slower
than others; you're asking the platform to do more work. Other
features could be optimized better than they are if needed, but the
content on the Web doesn't justify that investment. We can't
implement everything everyone wants and make it fast enough that
they don't notice it; like everyone else, we have to prioritize
work.</pre>
</blockquote>
<br>
Right! And Matt is trying to figure out how we can effectively
communicate our priorities, and how that fits in with our new
process.<br>
<br>
<br>
~ Gijs<br>
<br>
<blockquote cite="mid:20140518073838.GA12893@crum.dbaron.org"
type="cite">
<pre wrap="">
Don't assume that just because something is in the platform that
it's a good way to do what you want; often things are in the
platform for other reasons. Please ask.
-David
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>