1,295
edits
Gecko:AcceleratedFilters: Difference between revisions
→Filter Objects
| Line 37: | Line 37: | ||
We could try to map all filters down to GLSL and support only GLSL custom filters (using ANGLE on Windows). This would make it difficult to have a performant CPU implementation of common filters. We could pattern-match particular GLSL filters in a CPU implementation (and reject the rest entirely, probably), but that could be more fragile than having an actual API that captures which filters are supported by CPU implementations. Also, because a single filter could contain a sequence of (vertex shader, fragment shader) custom filter primitives, and an SVG filter can be a DAG of filter primitives, we can't boil a filter down to a single (vertex shader, fragment shader) combination anyway. | We could try to map all filters down to GLSL and support only GLSL custom filters (using ANGLE on Windows). This would make it difficult to have a performant CPU implementation of common filters. We could pattern-match particular GLSL filters in a CPU implementation (and reject the rest entirely, probably), but that could be more fragile than having an actual API that captures which filters are supported by CPU implementations. Also, because a single filter could contain a sequence of (vertex shader, fragment shader) custom filter primitives, and an SVG filter can be a DAG of filter primitives, we can't boil a filter down to a single (vertex shader, fragment shader) combination anyway. | ||
''Proposal: make a filter object a DAG of filter primitives, where each filter primitive is one of the SVG filter primitives | ''Proposal: make a filter object a DAG of filter primitives, where each filter primitive is one of the SVG filter primitives (which could be a GLSL custom filter)'' | ||
Many filter primitives take parameters. There are a few things to watch out for: | Many filter primitives take parameters. There are a few things to watch out for: | ||