On Mon, Jun 9, 2014 at 2:38 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote:
> ----- Original Message ----- > > From: "Rik Cabanier" <caban...@gmail.com> > > To: "Benoit Jacob" <jacob.benoi...@gmail.com> > > Cc: "Botond Ballo" <bba...@mozilla.com>, "dev-platform" < > dev-platform@lists.mozilla.org>, "Jet Villegas" > > <j...@mozilla.com> > > Sent: Monday, June 9, 2014 2:08:37 PM > > Subject: Re: C++ standards proposals of potential interest, and upcoming > committee meeting > > > > On Mon, Jun 9, 2014 at 1:50 PM, Benoit Jacob <jacob.benoi...@gmail.com> > > wrote: > > > > > 2014-06-09 16:27 GMT-04:00 Jet Villegas <j...@mozilla.com>: > > > > > > > It seems healthy for the core C++ language to explore new territory > here. > > > > Modern primitives for things like pixels and colors would be a good > > > thing, > > > > I think. Let the compiler vendors compete to boil it down to the > CPU/GPU. > > > > > > > > > In the Web world, we have such an API, Canvas 2D, and the "compiler > > > vendors" are the browser vendors. After years of intense competition > > > between browser vendors, and very high cost to all browser vendors, > nobody > > > has figured yet how to make Canvas2D efficiently utilize GPUs. > > > > > > Chrome, IE and Safari all have GPU accelerated backends with good > success. > > Deferred rendering is working very well. > We also use Skia's GL backend on some platforms, and D2D on windows. > They're strictly slower than reimplementing the app in WebGL. Sure, if you're just animating bitmaps with optional filters/compositing WebGL is faster. Drawing paths and text on the GPU requires complex shaders or tesselation and that require a lot of finessing. > > > 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. > > > > > > 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. Likely a hybrid approach where vectors are rendered by canvas 2D into a bitmap and those bitmaps are then animated by WebGL. A bitmap would be generated when a movieclip has: - a filter - a blend mode - "cache as bitmap" > > > > 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. > > > > > > > > --Jet > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
