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.
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?
> > > There are
> > > basically two kinds of Canvas2D applications: those for which GPUs have
> > > been useless so far, and those which have benefited much more from
> getting
> > > ported to WebGL, than they did from accelerated Canvas 2D.
>
This is just not true. Ignoring Shumway for the moment, what made Flash big
(before Youtube made it completely ubiquitous) was the fact that it enabled
simple creation and efficient delivery of complex and interactive
graphics/drawings/art/animations in 2D vector format.
In the 90s, that was important mainly because of bandwidth considerations,
which *might* be less important nowadays. I'm not convinced that this is
the case; we want to bring people in the developing worlds online (and not
overwhelm mobile networks in the developed world), I'd argue that the fact
that form factors have proliferated over the last few years, and that
they're unlikely to converge back anytime soon make having a good vector
format even more important. That format might well be SVG instead of
Canvas2D, but I have a hunch that your opinion of SVG isn't that much
higher, given that it provides much the same drawing primitives as Canvas2D
plus some more functionality that's probably hard to optimize.
> > 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.)
> > > 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?
Would it make sense to try to get one of them adopted?
till
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
