> It seems to me that we have arrived at the conclusion that a good drawing API
> should be mostly stateless (like Moz2D), instead of Cairo's stateful API. As
> a result we are currently removing all uses of the Cairo API and we will
> eventually remove Cairo from our codebase altogether (in favor of D2D via
> Moz2D on Windows and Skia via Moz2D elsewhere).
> 
> The C++ CS is free to standardize whatever they like, but if they ask for our
> opinion we probably want to point them at Moz2D instead of Cairo.
> 
> That having said, for maximum performance there is a fair amount of detailed
> knowledge callers need to have about the innards of Moz2D backends. You
> sometimes want to explicitly wrap a draw target around a texture and then
> use that texture in the compositor, etc. So I am not sure you can have a
> nice, non-leaky abstraction for 2D graphics in the language.
> 
> My best guess is that whatever they standardize will end up not being useful
> for high-performance applications. In that case, I wonder why bother. A
> library really might do just fine here.

> My best guess is that whatever they standardize will end up not being useful
> for high-performance applications. In that case, I wonder why bother. A
> library really might do just fine here.

I think at least one of the goals of the standard drawing API is to
make C++ easier to learn by allowing people learning the language
to create simple graphical applications without having to set up
third-party libraries or learn a complicated API.

I will ask for clarification at the SG 13 meeting (which I found
out will be tomorrow afternoon) regarding the drawing API's goals,
including whether high-performance applications are in scope.

Are the advantages of a stateless API over a stateful API specific
to high-performance applications, or are they more general?

I would like to learn more about the tradeoffs between stateful
and stateless drawing APIs. If anyone can point me to a resource
about this, I would be grateful.

Thanks,
Botond
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to