Use of D2D1PixelOptions.TrivialSampling
on shader w/ complex inputs causes problems
#770
Labels
D2D1PixelOptions.TrivialSampling
on shader w/ complex inputs causes problems
#770
This isn't a ComputeSharp.D2D1 bug, but I think it's an easy mistake that should be flagged by the source generator. It's something that has caused me to waste a bunch of time in the debugger for a mistake that was rather difficult to figure out.
To repro, take a shader that has any complex input and add a
[D2D1PixelOptions(D2D1PixelOptions.TrivialSampling)]
attribute on it. Once you run the shader, you'll either see all sorts of missing gaps with transparent pixels, or if you have the debug layer on you'll see random colors in those gaps instead. Presumably D2D fills the texture with those solid colors to aid debugging.Direct2D defines trivial sampling as being applicable only to shaders that 1) only use simple inputs, and 2) produce all-zero output for all-zero input. This allows it to do optimizations like skipping the shader entirely if it knows the input is all-zeros. An example would be an shader with an output region of e.g.
[x=0, y=0, w=100, h=100]
being plugged into a shader with an output region of e.g.[x=0, y=0, w=200, h=200]
. The right and bottom edges of the input are known by D2D to be zero, so it only needs to run the second shader on the top left quadrant.Here's an example using my custom Gaussian Blur shaders, with the D2D debug layer enabled:
The text was updated successfully, but these errors were encountered: