jeske's picture

decoupling render-size from window-size?

I'm looking for some advice on de-coupling the size of render-surfaces from the size of the OpenTK.GameWindow nativewindow resolution -- for use on hiDPI systems. For example, the Macbook Pro retina display DPI is really high, and 3d rendering the native pixels is quite expensive. I'd prefer to render 3d content at 1/2 resolution. At the same time, I'd like to render my 2d HUD UI at "native" full resolution pixel sizes.

I believe one way I can achieve this is to make a half-resolution FBO target for my 3d scene. Render the 3d scene. Splat that FBO onto the back-buffer (upscaling it). Then render my 2d scene at "full resolution" onto the backbuffer. Then swapbuffers.

Anything wrong or inefficient about that?

I'm also considering using 2 FBO "backing stores" for the 3d and 2d UI respectively. My application has a fairly "desktop style" overlapping window HUD, and waiting for the 3d repaint in order to update a simple 2d UI operation can be quite slow. It would be nice if I could do a rectangular "dirty repaint" more typical of 2d GUIs... This requires storing a copy of the previous 3d scene, so I can quickly repaint 2d dirty regions.

Any thoughts?