P.S. The 1% figure there was a bit harsh, make it 5%...
2014-02-24 7:49 GMT-05:00 Benoit Jacob <jacob.benoi...@gmail.com>: > 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
