I thought that nux will only read from the bound framebuffer object if nux actually knew about its existence. In this case, the compiz fbo is bound, but nux doesn't know about it, so it will read from the real backbuffer instead (which is not what you want).
I did just recently add a method to WindowCompositor to handle this case - see WindowCompositor::RestoreMainFramebuffer. You can probably use that in combination with SetReferenceFramebuffer, eg, RestoreMainFramebuffer -> SetReferenceFramebuffer -> CreateTextureFromBackbuffer.
A less roundabout way of doing that would be to have a GLFramebufferObject that unity *owns* and then we bind that and paint the compiz one into it. Then pass that one as the device texture. Once the blit framebuffer code is landed, we can use that on the unity side too.
Hmm, is this correct?
16 + nux::ObjectPtr< nux::IOpenGLTex ture2D> bg_texture = engine- >CreateTextureF romBackBuffer( 0, 0,
17 + graphics_
18 + screen->width(),
19 + screen->height());
I thought that nux will only read from the bound framebuffer object if nux actually knew about its existence. In this case, the compiz fbo is bound, but nux doesn't know about it, so it will read from the real backbuffer instead (which is not what you want).
I did just recently add a method to WindowCompositor to handle this case - see WindowComposito r::RestoreMainF ramebuffer. You can probably use that in combination with SetReferenceFra mebuffer, eg, RestoreMainFram ebuffer -> SetReferenceFra mebuffer -> CreateTextureFr omBackbuffer.
A less roundabout way of doing that would be to have a GLFramebufferObject that unity *owns* and then we bind that and paint the compiz one into it. Then pass that one as the device texture. Once the blit framebuffer code is landed, we can use that on the unity side too.