: Implementing CSS/SVG filters
when the accelerated filters will be available ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2013-06-05 8:38 AM, Robert O'Callahan wrote:
We had a meeting about filter implementation in Taipei.
My recollections, plus some interpolation on a few issues we didn't
directly address, are here:
https://wiki.mozilla.org/Gecko:AcceleratedFilters#Implementation
Markus is likely to start
This sounds like an awful lot of work, a lot more than some glue code and code
deletion. It sounds like you are proposing to make Moz2D pretty much a general
purpose 2D and 3D graphics library, touch (to some effect) the whole of the
graphics code, and switch to using new libraries which have
On May 1, 2013, at 1:06 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, May 1, 2013 at 6:41 PM, Andreas Gal g...@mozilla.com wrote:
Both Skia/SkiaGL and D2D support basically all the effects and filters we
want.
D2D does not support GLSL custom filters. We'd need ANGLE/GLContext
On Wed, May 1, 2013 at 8:20 PM, Andreas Gal g...@mozilla.com wrote:
We should probably start with the CPU-based fallback path. We can then try
that with SkiaGL to see what the performance looks like (the
GLContext-based implementation, essentially). Should we file a couple bugs?
I might
On 5/1/2013 12:11 AM, Andreas Gal wrote:
You propose SIMD optimization for the software fallback path. I wonder whether
we should focus on one fast GPU path via GLSL, and have one precise, working,
I-don't-care-how-slow CPU fallback. All hardware made the last few years will
have a GPU we
On 2013-05-01 9:31 AM, Benjamin Smedberg wrote:
On 5/1/2013 12:11 AM, Andreas Gal wrote:
You propose SIMD optimization for the software fallback path. I
wonder whether we should focus on one fast GPU path via GLSL, and
have one precise, working, I-don't-care-how-slow CPU fallback. All
This is a fairly important feature that people want to get working on soon,
but there are quite a few design issues to settle on before we go too far.
I've tried to summarize the requirements, and my ideas about the design,
here:
https://wiki.mozilla.org/Gecko:AcceleratedFilters
Please tear this
OpenCL could definitely do this and it interoperates pretty well with GL,
however, its basically not available anywhere.
Andreas
On Apr 30, 2013, at 9:26 PM, Kevin Gadd kevin.g...@gmail.com wrote:
Could you implement all the filters once in OpenCL to get adequate
performance on-CPU (with
On Wed, May 1, 2013 at 4:11 PM, Andreas Gal g...@mozilla.com wrote:
I wonder whether we should focus on one fast GPU path via GLSL, and have
one precise, working, I-don't-care-how-slow CPU fallback.
I agree that should be our top priority, and it may not be worth doing CPU
SIMD at all. But if
On Apr 30, 2013, at 10:28 PM, Andreas Gal g...@mozilla.com wrote:
On Apr 30, 2013, at 9:56 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, May 1, 2013 at 4:11 PM, Andreas Gal g...@mozilla.com wrote:
I wonder whether we should focus on one fast GPU path via GLSL, and have one
On Wed, May 1, 2013 at 5:28 PM, Andreas Gal g...@mozilla.com wrote:
Should we hide the temporary surface generation (when needed) within the
API?
GLContext::Composite(Target, Source, EffectChain, Filters)
And if multiple shaders or passes are needed, we create a temporary
surface on the
On Apr 30, 2013, at 10:36 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, May 1, 2013 at 5:28 PM, Andreas Gal g...@mozilla.com wrote:
Should we hide the temporary surface generation (when needed) within the API?
GLContext::Composite(Target, Source, EffectChain, Filters)
And if
13 matches
Mail list logo
