GDI rendering on top of OpenGL
-
Any tips on doing GDI rendering on top of OpenGL? We're doing our OpenGL rendering, then calling SwapBuffers, then doing GDI rendering on the same DC. This works fine with SW rendering pixel formats. When using HW accelerated pixel formats the window update/clipping/refresh is different the GDI rendering doesn't always update if you obscure the window with a dialog for example. So I thought I'd ask in case we're going about it the wrong way.
-
Any tips on doing GDI rendering on top of OpenGL? We're doing our OpenGL rendering, then calling SwapBuffers, then doing GDI rendering on the same DC. This works fine with SW rendering pixel formats. When using HW accelerated pixel formats the window update/clipping/refresh is different the GDI rendering doesn't always update if you obscure the window with a dialog for example. So I thought I'd ask in case we're going about it the wrong way.
Well I found one solution to this. We've overridden OnEraseBkgnd in our view window and we just return TRUE. I added a call to Invalidate(FALSE) and that cleared up the GDI rendering. It looks like the GDI rendering was getting called, but the only region being allowed to update was the obscured region.
-
Any tips on doing GDI rendering on top of OpenGL? We're doing our OpenGL rendering, then calling SwapBuffers, then doing GDI rendering on the same DC. This works fine with SW rendering pixel formats. When using HW accelerated pixel formats the window update/clipping/refresh is different the GDI rendering doesn't always update if you obscure the window with a dialog for example. So I thought I'd ask in case we're going about it the wrong way.
You could also try rendering onto a memory bitmap, then use GDI on that and blit that onto your window. Because of the blit this could be a bit slower though. I see you already solved your problem but i thought i mention this possibility too.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
You could also try rendering onto a memory bitmap, then use GDI on that and blit that onto your window. Because of the blit this could be a bit slower though. I see you already solved your problem but i thought i mention this possibility too.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
Blitting a bitmap may hide some part of the OpenGL rendered scene. Otherwise has to go for Transperant blitting.
-Sarath. "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
-
Blitting a bitmap may hide some part of the OpenGL rendered scene. Otherwise has to go for Transperant blitting.
-Sarath. "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts, An Article - Understanding Statepattern
What do you mean? What i meant is not to draw GDI things onto a bitmap and then blit that onto the surface OpenGL rendered to, i mean, make OpenGL render onto a bitmap, use GDI on that and then display it on the window. See this.[^]
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
What do you mean? What i meant is not to draw GDI things onto a bitmap and then blit that onto the surface OpenGL rendered to, i mean, make OpenGL render onto a bitmap, use GDI on that and then display it on the window. See this.[^]
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
We do render OpenGL to an offscreen bitmap in some places, but not for our main rendering. If you render OpenGL to an offscreen bitmap are you still able to take advantage of hardware accelerated pixel formats? We've seen issues with trying to do that.
-
We do render OpenGL to an offscreen bitmap in some places, but not for our main rendering. If you render OpenGL to an offscreen bitmap are you still able to take advantage of hardware accelerated pixel formats? We've seen issues with trying to do that.
I'm not sure...that might vary dependant on drivers and hardware i guess.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <