From your blog post: > SG 13′s main intended purpose for such an API is to allow people learning > C++ and writing graphical applications to do so easily, without having to > rely on third-party libraries or learning complex APIs. In the long-term, > however, they would like the drawing API to be useful for people writing > application frameworks and high-performance applications as well.
The first goal --- to make learning and simple development easier --- seems like a decent goal for the standard library, and one that could indeed conceivably be achieved by an API derived from Cairo (or Moz2D, or any other typical imperative 2D API). But the long-term goal mentioned above, "to be useful for people writing [...] high-performance applications as well", assuming that "high-performance" means being not too far from hardware limits, isn't really compatible with that, and if that is ever to be achieved, it would have to be thought about in depth from day one, and in particular, nobody really knows an incremental path from "a familiar imperative 2D API like Cairo (or Moz2D)" to "enable high-performance applications". The browser community is stuck with a 2D API that is convenient for casual usage and learning --- Canvas2D --- but has now to optimize that as much as possible. And with implementations such as Moz2D using Direct2D, or Skia/GL, there is no denying that a great deal of effort goes into that, with very significant advances being made towards running Canvas2D as fast as possible. That might confuse outside observers into believing that that means that these 2D APIs can be efficient, which they can't. "As fast as possible" here generally means 1% of hardware limits, and already using costly trade-offs such as large texture caches which are already a source of problems on memory-constrained devices. For example, people might be confused by browser-based demos using Canvas2D to boast "1000 flying kittens at 60 FPS" or some similar feat on a typical desktop computer. While that may seem impressive to people, that is typically only 1% of what that typical desktop hardware can do, and the way to get the remaining 99% of performance is to stop using Canvas2D (or any similar 2D API, such as Moz2D or Cairo or Direct2D) and instead use directly a lower-level graphics API like WebGL (or OpenGL or Direct3D). See e.g. Jeff's post, http://muizelaar.blogspot.ca/2011/02/drawing-sprites-canvas-2d-vs-webgl.html. So we are already at the point where, when people ask "how can I make this Canvas2D game run more efficiently" the best answer we can give them is "rewrite it to use WebGL instead". Similarly, if the C++ committee accepts a traditional (e.g. Cairo-inspired) 2D API with the eventual goal of enabling high-performance applications, they will probably have to give up that goal and tell application developers that were hoping for it, that they should rewrite their applications using OpenGL instead. Does the C++ committee realize that? To summarize, I believe that for that project to be reasonable, the C++ committee should at least explicitly make high performance a non-goal, even in the long run. Benoit 2014-02-23 21:53 GMT-05:00 Botond Ballo <bba...@mozilla.com>: > >> 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. > > > http://robert.ocallahan.org/2011/09/graphics-api-design.html > > > FWIW I don't think any of this affects Mozilla. We aren't going to use > the > > standard C++ graphics library ... unless it ends up being Moz2D or > something > > exactly like it :-). > > I summarized what happened at the SG13 meeting in my blog post > about the committee meeting [1]. > > One interesting point that came up is that, since the thing being > standardized is cairo's interface, not its implementation, the > inefficiency that arises by having to go through cairo's public > stateful layer, then its internal stateless layer, and then a > backend library's stateful layer, can be avoided - an implementer > can simply implement the standard (stateful) interface directly > in terms of the stateful backend interface. > > Also, as I mention in my blog post, while the cairo proposal is > being actively worked on and SG13 likes its direction, it's not > too late to bring forward a competing proposal. If someone is > interesting in writing a proposal based on Moz2D, I would be > happy to present it at the next meeting. > > Cheers, > Botond > > [1] > http://botondballo.wordpress.com/2014/02/22/trip-report-c-standards-committee-meeting-in-issaquah-february-2014/#sg13 > _______________________________________________ > 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
