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
hardware made the last few years will have a GPU we support.
I'm surprised at this statement, and suspect that it's not true.
In general we don't support GPU on most integrated intel graphics
hardware on Win7. We are slowly starting to support this on Win8. But
we actively blocklist a pretty sizeable chunk of graphics
hardware/driver versions even on pretty modern computers.
Even when we initially have full support, we still blocklist things
pretty frequently, because of driver updates causing stability problems
or other even more bizzare things (see the AMD crashers that depend on
the precise build of Firefox). Our first priority should be GPU
acceleration, just as Andreas says, but a performant CPU implementation
would be very useful.
Perhaps the correct answer here is to not support some kinds of filter
effects on older hardware, rather than supporting them in very slow
paths. Do we have a sense for whether especially CSS filters would
gracefully degrade in general?
Not supporting CSS filters on older or blacklisted hardware doesn't fill
me with joy, but it'd be OK. If we can implement it in software, though,
it'd be nice if we did. (For example, we implemented 3D transforms in
software using Pixman's support.)
joe
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
