Blending SwapChains

[gibssa]

Hi again Filament team,

I'm stuck again, this time trying to blend two SwapChains together:

1. "Expensive Window" is very expensive, but rarely needs to be re-drawn (<1hz)
2. "Main Window" is cheap, and can be drawn every frame (60hz)

I can simply overlay Expensive Window on top of Main Window (the "painter's algorithm" hack works for me).

Here's a snippet of my code:

  main_swap_chain = engine_->createSwapChain();

  headless_swap_chain = engine_->createSwapChain(
        viewport_width, viewport_height,
        filament::SwapChain::CONFIG_TRANSPARENT |
            filament::SwapChain::CONFIG_READABLE
    );

  filament::Renderer::ClearOptions clear_options;
  clear_options.clearColor = {0.0, 0.0, 0.0, 1.0};
  clear_options.clear = true;
  clear_options.discard = true;
  renderer->setClearOptions(clear_options);


void Render() {
    if (renderer->beginFrame(main_swap_chain)) {
      renderer->render(main_window.view);
      renderer->endFrame();
    }

    if (renderer->beginFrame(off_screen_window.headless_swap_chain)) {
      if (expensive_window_needs_to_be_redrawn) {
        renderer->render(off_screen_window.view);
      }
      renderer->copyFrame(main_swap_chain, main_view->getViewport(),
                          off_screen_window.view->getViewport(),
                          filament::Renderer::COMMIT
      );
      renderer->endFrame();
    }
}

The result works, but has screen-flickering, probably caused by disagreeing SwapChain "COMMIT"s from the renderer->endFrame() fighting against renderer->copyFrame(COMMIT).

My questions are:

• is renderer->copyFrame() the correct approach to overlay my two SwapChains here?
• should I use the RenderTarget API instead?
  • if so, is there a simpler way to get the RenderTarget's Texture pixels drawn into the main SwapChain?
  • (that is, outside of introducing a custom matc shader TextureSampler -- I see the rendertarget.cpp sample, but I'd like to avoid introducing a third View with its own Renderable + ORTHO projection matrix math just to get texture UV pixels drawn on screen...)
• or would you instead recommend using multiple SurfaceView / CAMetalLayer and overlay pixels at the OS level?
  • (I'm curious if this would cost extra GPU memory bandwidth?)

Thanks again!

[romainguy]

The cheaper option on Android is going to be 2 SurfaceView. It bypasses the GPU. Otherwise, don't use copyFrame(), but draw your render target's texture as a quad (you don't need a separate View for that, just a Fullscreen quad or triangle with the appropriate material).

[gibssa]

Do you happen to know if two MTKViews is similarly cheap for iOS?

(thanks @romainguy)

[gibssa]

EDIT: no worries about this MTKView question, it seems like the "double SurfaceViews" approach has the two overlaid frame buffers slightly out-of-sync with each other.

I'll come back to this, going down the path of the full-screen quad, and close this discussion out once I figure it out.

Thanks for the quick turnaround suggesting not to use copyFrame()

[gibssa]

I ended up deciding against this (complexity, overhead). Thanks for the help!