So far I’ve just messed around with filters whose inputs and outputs were the same size. I’m now attempting to satisfy my own feature request for a general horizontal coordinate transform device. To supply an output over a requested worldspace extent will require input data from very different worldspace extents.
As one specific example, let the device output a 45 degree rotation of its one input. To fill an N x N output grid without gaps, it needs access to an 1.414N x 1.414N input grid. As a second example, let the device output a M:1 compression along the X axis. To fill an N x N output grid without gaps, it needs access to an N*M x N input grid.
I don’t know how to do that, and now I realize there’s a lot about the WM architecture I don’t understand. So the following questions may just be “wrong questions”…
Q1) I see a few references in the PDK to “proxy builds”. Is this where the desired render extent gets expanded into specific build extents for each device? What’s the sequence of events relative to proxy builds and Activate calls?
Q2) Can/Are BuildContexts be modified (or a new proxy build be triggered) on the basis of parameter change? (Assuming: yes)
Q3) Ignoring output tiling for the moment, will a device ever get multiple “fragmentary” Activate calls on a single world build, to fill in various subregions of its output? Or, can a device ever call RetrieveData multiple times on the same port to get different input packets on a single Activate call? (Assuming: no)
Q4) If a device needs input from a known non-square shape, can it call for multiple input packets that cover that shape more efficiently than the single enclosing square of input? (Assuming: no)
Q5) If it’s possible to achieve my objective, are there any code samples to look at? Certainly none of the simple examples in the PDK do this. I’ve looked at howardzzh’s Downsizer example from 2007. While that generates an output smaller than the input, there’s nothing in that code that calls for any particular input (or output) size.