----- Original Message -----
> On Mon, Jun 9, 2014 at 9:45 PM, Benoit Jacob <jacob.benoi...@gmail.com>
> wrote:
> > I would like the C++ committee's attention to be drawn to the dangers, for
> > committee, to try to make decisions outside of its domain of expertise. I
> > see more potential for harm than for good in having the C++ committee join
> > the ranks of non graphics specialists thinking they know how to do
> > graphics...
>
> > If that helps, we can give a pile of evidence for how having generalist
> Web
> > circles trying to standardize graphics APIs has repeatedly given
> > unnecessarily poor APIs...
>
> It sounds to me like you're opposed to graphics APIs that try to cater to
> non-graphics specialists, period. Do you think that it's outright
> impossible to design a good API with this intent? If you don't, then I'm
> sure it's possible to give more constructive feedback than this, frankly,
> insulting non-specific criticism of essentially the entire idea of
> standardizing anything graphics-related.
Why put this into core C++? Why not leave it to libraries?
What's the core problem trying to be solved here? It's either:
A) We want a 2D graphics API in C++.
or
B) We want to make it easy to do 2D graphic in C++.
The reason it feels like B implies A is that using libraries is a terrible pain.
Fix the cause of the friction for using existing graphics APIs, instead of just
treating the symptoms.
>
>
> On Mon, Jun 9, 2014 at 11:38 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote:
>
> > We also use Skia's GL backend on some platforms, and D2D on windows.
> > They're strictly slower than reimplementing the app in WebGL.
> >
>
> Which kind of app are you talking about here? All The Apps? Including every
> single game ever made with Canvas2D?
The short answer is 'yes, especially the games'. It has been an uphill battle
to raise awareness of this in games, but the reality is that if you want
performant graphics, don't use Canvas2D. Canvas2D should in fact be 'considered
harmful' to performance, for most games.
GL-based APIs have orders of magnitude better performance in a number of areas,
at the expense of having no API to do things CPUs are good at, like fonts,
paths, etc.
How to handle these with WebGL? Rasterize them with Canvas2D and upload them to
WebGL
once, reusing them hundreds of times. This is what SkiaGL tries to do anyways.
There is overhead to using a non-purposed-designed API. Our accelerated
Canvas2D backends
try really hard, but they will not be faster than someone doing to low-level
work
themselves. Games (which are largely blitting-bound) will just be faster if you
can
tell the hardware more explicitly what you want.
Note that this an instance of the 'sufficiently smart compiler/runtime' problem,
and that for C++, I can't imagine there will be a SkiaGL-like runtime to
translate slow
2D graphics commands into faster GL/D3D dispatches to drivers. We're then left
with a purely-slow, beginner-targeted 2D graphics API.
I'll note that in OpenGL, we used to have beginner-friendly APIs which allowed
for
drawing things vertex-by-vertex, and manipulating a primitive shading pipeline.
But it was slow, and considered-harmful. Eventually, we managed to get rid of
it.
OpenGL is moving towards only offering a powerful base API. If you want an
easier
API, use a library.
>
>
> > > That is not true. For instance, do you think mozilla's shumway would be
> > > better and reliable if it was written in WebGL?
> > It depends on the primitives shumway receives. If Flash uses a 2d-like API
> > like skia/cairo/etc., then it is probably not worth the effort to
> > reimplement the awful-for-GL parts of those APIs.
> > If there's some performant subset that can be identified, then yes, doing
> > a WebGL path for that would have a higher performance ceiling.
> >
>
> We (the Shumway team) looked into implementing all the vector stuff in
> WebGL. We might end up using exactly this approach, but for the general
> case we hope we can continue relying on Canvas2D. ("hope", because Flash
> does some things that are hard to impossible to represent in Canvas2D.
> They're not important for this discussion, though: the ability to
> faithfully implement a legacy system isn't a good criterium for the quality
> of, well, anything.)
Ok, but aware that you are almost certainly leaving some performance on the
table. (This
is probably fine for Shumway though. Ideally people aren't authoring
performance-sensitive Flash applications anymore)
>
> > > > There will always be the argument for keeping such things out of
> > Systems
> > > > > languages, but that school of thought won't use those features
> > anyway. I
> > > > > was taught to not divide by 2 because bit-shifting is how you do fast
> > > > > graphics in C/C++. I sure hope the compilers have caught up and such
> > > > > trickery is no longer required--Graphics shouldn't be such a black
> > art.
> >
>
> I agree with this. The particular approach the C++ committee chose might
> be a bad one, and I do think that domain experts should do the majority of
> the design work for an API like this. Design by committee is difficult and
> slow at best and pretty bad at worst, so it might well be that it shouldn't
> be done for a case like this. Note, though, that the C++ committee
> apparently tried to avoid exactly that by basing their work on an
> established API. Are there better candidates for this approach than Cairo?
It should be noted that we're currently minimizing our use of Cairo in Gecko,
so I think it would clearly be a mistake to take an API that *we are actively
moving away from* and put it in C++.
> Would it make sense to try to get one of them adopted?
I don't think it makes sense for any of them to be adopted. It'd be way nicer to
add support to the language for easily importing an existing 2D graphics
library,
instead of trying to enshrine one in the spec. Trying to shoehorn any single
graphics
API into the spec seems like tremendous scope creep, to me.
Why would you put something beginners-only in the spec if experts should
basically never use it?
What happens when there's a better design for an API? Add that to the spec too?
Is there a deprecation path for unwanted features?
-Jeff
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
