Re: Skia Content on OS X

[Patrick Walton]

Thanks for the info! This is very interesting to us in Servo.

Do you have any performance measurements that support the statement "While
it would be nice to use the GPU, we’re not totally confident that using the
GPU to render content is quite worth it."? We have evidence on our side to
support this too (and in fact it's one of the motivations for WebRender),
but it's be great to have comprehensive data to back it up.

Patrick
On Mar 22, 2016 10:56 AM, "Mason Chang"  wrote:

> Hi David,
>
> The main benefit is architectural with a huge simplification of our
> graphics code, with a nice side benefit of performance. As it stands today,
> we have multiple different rendering paths for each platform (Linux, OS X,
> Windows). That means every time we hit a graphics bug, we have to know
> three APIs that render just slightly different and we have to dig through
> each backend to figure out what’s going on. These all have slightly
> different performance characteristics as well, which takes some time. We
> don’t generally get a lot of benefit from having a distinct backend for
> platform also because other than on Windows, we’re not using the GPU for
> content rendering. This essentially means we’re spinning a lot of wheels
> and cost on small fixes on non-windows platforms for little benefit. [1].
> This is especially true when you consider that we have special backends for
> both Linux and OS X which make up 2.6% of our user base.
>
> With Skia, we can unify all of our graphics pipeline across all platforms
> other than Windows for content rendering. It uses CPU rendering and because
> of that, fixes on one platform translate much better across other platforms
> that use Skia. While it would be nice to use the GPU, we’re not totally
> confident that using the GPU to render content is quite worth it. It’s also
> quite nice that micro-level optimizations at the backend level can mostly
> be done for us as Skia is optimizing performance with Chrome as one of
> their use cases. e.g., on Mac, scaling content on the CPU was 2-3x faster
> with Skia versus CG.
>
> Overall, it’s mostly a clean up operation so we spend less time fixing
> each individual platform.
>
> Please let me know if you have any more questions.
>
> Thanks,
> Mason
>
> [1] https://people.mozilla.org/~danderson/moz-gfx-telemetry/www/
>
> > On Mar 22, 2016, at 8:21 AM, Mike de Boer  wrote:
> >
> > I was also quite curious, so I started clicking up the hierarchy of that
> bug and ended up at:
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1154825#c1>
> >
> > (comment 2 is also useful info)
> >
> > Ultimate goal: no more checkerboarding in APZ. But Mason is the
> authority here, methinks :-)
> >
> > Cheers,
> >
> > Mike.
> >
> >> On 22 Mar 2016, at 15:45, David Rajchenbach-Teller 
> wrote:
> >>
> >> Out of curiosity, what's the benefit?
> >>
> >> On 22/03/16 15:44, Mason Chang wrote:
> >>> Hi all,
> >>>
> >>> We're changing the default graphics backend on OS X from CoreGraphics
> to
> >>> Skia. In the best case, you should notice no difference.
> >>>
> >>> If you see any graphics artifacts on mac, please file a bug and make it
> >>> block bug 1207332 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1207332>.
> >>> You can verify that the artifact you're seeing is due to the switch by
> >>> going to about:config, set the preference "gfx.content.azure.backends"
> to
> >>> "cg", restarting Firefox and seeing if the artifact still appears.
> >>>
> >>> Thanks to Lee Salzman, Jeff Muizelaar, and Markus Stange for their
> >>> tremendous efforts in getting this accomplished.
> >>>
> >>> Thanks,
> >>> Mason
> >>> ___
> >>> dev-platform mailing list
> >>> dev-platform@lists.mozilla.org
> >>> https://lists.mozilla.org/listinfo/dev-platform
> >>>
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: HTML5

[Patrick Walton]

On 9/21/14 6:00 AM, James Graham wrote:

In the longer term, one might hope that bugfixes will produce new
testcases that could be upstreamed, and Servo might need a proper
testsuite to achieve interoperability. Having said that, Servo has so
far not produced a significant number of tests, which has been a little
surprising as they have been implementing some of the core pieces of the
platform which are indeed under-tested. I suspect this is because the
skills, interests and goals of the team are around producing code rather
than tests. For people making small contributions it would also be
rather off-putting to be told no you can't land this fix that makes
Wikipedia look better without a comprehensive testsuite for the relevant
feature. However if we as an organisation really care about testing
core platform features which already have an implementation in gecko,
one way to achieve that would be to give someone working on Servo the
explicit job of creating testsuites for the big-ticket features they
implement as they implement them.


We land simple reftests whenever we fix bugs in Servo in order to 
prevent regressions. Our big-ticket items tend to be tested by 
comprehensive reftests that test many things at the same time (e.g. the 
border test).


On the Servo team we don't have the manpower to dedicate one member to 
writing comprehensive test suites. Our research goals are oriented 
toward proving that parallel layout works on the Web, which means, at 
this time, showing that real, popular Web sites look correct and 
demonstrate parallel speedups. Standards work, including writing test 
suites, is useful, but has to be secondary to proving the viability of 
the project.


Patrick

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform