Gecko:AcceleratedFilters: Difference between revisions

Line 35: Line 35:
== Filter Objects ==
== Filter Objects ==


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 filters (using ANGLE on Windows). This would make it difficult to have a performant CPU-only implementation of standard 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 a real API that captures which filters are supported by CPU implementations. Also, because a single filter can be 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; we'd need something at least as complex as a DAG of GLSL filters.


''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)''
''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)''
1,295

edits