On 12/11/2014 17:30, Jack Moffitt wrote:
> On 12/11/2014 17:23, Cameron Zwarich wrote:
>> On Nov 11, 2014, at 4:55 PM, Andreas Gal wrote:
>>> Does anyone have profiling numbers that Azure on top of Skia has a
>>> measurable performance overhead?
>>
>> The overhead referred to here is administrative overhead. We pull in other
>> pieces of Gecko outside of Azure proper in order to use Azure in Servo.
>
> As I remember, this is unintentional. Azure is now hosted out of tree
> and shouldn't have this problem anymore, although I haven't checked. I
> talked to Bas about this last October because at that time I had
> recently done an Azure upgrade and had to redo all the headers because
> XPCOM had snuck into it. Perhaps this can now be fixed?
If it's not, it sounds like it might be useful to have a tracking bug filed in:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics
with a summary along the lines of "Make Moz2D more Servo friendly" with specific
issues filed as blockers against that one.
> Perhaps the right lesson to be learned here is that we should make it
> possible for Servo to use Azure without any additional pieces from Gecko,
> and to expose native surfaces backing Azure draw targets in a more
> uniform way.
DrawTarget::GetNativeSurface provides this in general (although the older
version of Moz2D that servo is currently using doesn't implement
DrawTargetSkia::GetNativeSurface). If you want to get hold of the
GrContext/SkCanvas, it looks like it would be trivial to extend
DrawTargetSkia::GetNativeSurface to support that just as DrawTargetCairo
supports getting cairo contexts/surfaces (from which more platform specific
objects can be obtained). Again a bug in the Graphics component of bmo would be
appropriate.
Upstreaming your patches and/or filing upstream bugs to get the API you need
should help avoid the administrative overhead in future. :)
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
