Bugzilla

I think I have a reasonable repro case to start plumbing: if I use this yaml file...

```
root:
  items:
    - type: "stacking-context"
      perspective: 100
      perspective-origin: 100 100
      items:
        - type: "stacking-context"
          filters: blur(2)
          transform: rotate-x(15)
          items:
            - image: checkerboard(2, 8, 64);
              bounds: [40, 40, 516, 516]
        - image: checkerboard(2, 32, 2);
          bounds: [700, 40, 68, 68]
```

... and artifically lower `MAX_SURFACE_SIZE: f32 = 256.0` then it's interesting to see what happens in RenderDoc:
* first we do the perspective warp into a render target;
* then we ping-pong 2 passes to do the blur;
* and that goes into a tile cache.

The order of operations is thus different from what we get with regular "establishes a raster root":
* first blit into a (larger) rendertarget, without perspective;
* ping-pong 2 passes for blur;
* apply the perspective warp when rasterizing into the tilecache.

The latter sounds more correct based on guessing what the yaml's order of operations is supposed to be.

Thus I think I can start the plumbing by using the order of operations as a test case: lower `MAX_SURFACE_SIZE` and hack away until it manages to do the latter set of renderpasses?

I think I have a reasonable repro case to start plumbing: if I use this yaml file...

```
root:
  items:
    - type: "stacking-context"
      perspective: 100
      perspective-origin: 100 100
      items:
        - type: "stacking-context"
          filters: blur(2)
          transform: rotate-x(15)
          items:
            - image: checkerboard(2, 8, 64);
              bounds: [40, 40, 516, 516]
        - image: checkerboard(2, 32, 2);
          bounds: [700, 40, 68, 68]
```

... and artifically lower `MAX_SURFACE_SIZE: f32 = 256.0` (nested picture no longer establishes a root), then it's interesting to see what happens in RenderDoc:
* first we do the perspective warp into a render target;
* then we ping-pong 2 passes to do the blur;
* and that goes into a tile cache.

The order of operations is thus different from what we get with regular "establishes a raster root":
* first blit into a (larger) rendertarget, without perspective;
* ping-pong 2 passes for blur;
* apply the perspective warp when rasterizing into the tilecache.

The latter sounds more correct based on guessing what the yaml's order of operations is supposed to be.

Thus I think I can start the plumbing by using the order of operations as a test case: lower `MAX_SURFACE_SIZE` and hack away until it manages to do the latter set of renderpasses?

I think I have a reasonable repro case to start plumbing: if I use this yaml file...

```
root:
  items:
    - type: "stacking-context"
      perspective: 100
      perspective-origin: 100 100
      items:
        - type: "stacking-context"
          filters: blur(2)
          transform: rotate-x(15)
          items:
            - image: checkerboard(2, 8, 64);
              bounds: [40, 40, 516, 516]
        - image: checkerboard(2, 32, 2);
          bounds: [700, 40, 68, 68]
```

... and artifically lower `MAX_SURFACE_SIZE: f32 = 256.0` (nested picture no longer establishes a root), then it's interesting to see what happens in RenderDoc:
* first we do the perspective warp into a render target;
* then we ping-pong 2 passes to do blur the result of step 1;
* and that goes into a tile cache.

The order of operations is thus different from what we get with regular "establishes a raster root":
* first blit into a (larger) rendertarget, without perspective;
* ping-pong 2 passes to blur this flat output of step 1;
* apply the perspective warp when rasterizing into the tilecache.

The latter sounds more correct based on guessing what the yaml's order of operations is supposed to be.

Thus I think I can start the plumbing by using the order of operations as a test case: lower `MAX_SURFACE_SIZE` and hack away until it manages to do the latter set of renderpasses?

I think I have a reasonable repro case to start plumbing: if I use this yaml file...

```
root:
  items:
    - type: "stacking-context"
      perspective: 100
      perspective-origin: 100 100
      items:
        - type: "stacking-context"
          filters: blur(2)
          transform: rotate-x(15)
          items:
            - image: checkerboard(2, 8, 64);
              bounds: [40, 40, 516, 516]
        - image: checkerboard(2, 32, 2);
          bounds: [700, 40, 68, 68]
```

... and artifically lower `MAX_SURFACE_SIZE: f32 = 256.0` (nested picture no longer establishes a root), then it's interesting to see what happens in RenderDoc:
* first we do the perspective warp into a render target;
* then we ping-pong 2 passes to blur the result of step 1;
* and that goes into a tile cache.

The order of operations is thus different from what we get with regular "establishes a raster root":
* first blit into a (larger) rendertarget, without perspective;
* ping-pong 2 passes to blur this flat output of step 1;
* apply the perspective warp when rasterizing into the tilecache.

The latter sounds more correct based on guessing what the yaml's order of operations is supposed to be.

Thus I think I can start the plumbing by using the order of operations as a test case: lower `MAX_SURFACE_SIZE` and hack away until it manages to do the latter set of renderpasses?