----- Original Message -----
> 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.
If it's not a good candidate for GPU acceleration, just do it on the CPU.
Games and other performance-sensitive apps generally benefit from at least
hardware-accelerated blitting and blending.
Even the browser, which is full of text, paths, gradients, and more, we find
it advantageous to eventually composite with accelerated 3D APIs (given the
need to scroll and zoom), even if we rasterize many of the above on the CPU.
>
>
> > > > 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"
Indeed, for WebGL apps, the general idea for text (for example) is to rasterize
to a Canvas2D canvas, and then use that canvas as a texture in WebGL. (write
once,
draw often) FWIW, this is basically the web-API version of what we do in Gecko
for
page rasterization.
I should address the idea that we could use cpp2d to do non-GPU rasterization:
I guess, but why? It gives us a default, but is that needed? In Gecko, we
certainly
would take very sparing use of it, if at all. (We already have Cairo, after all)
If C++ wants a default, just package Cairo (or something else) as a library
alongside
Clang/LLVM or GCC.
-Jeff
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
