Making composite managers go along with OpenGL

Well, as everyone knows by now, OpenGL applications (and probably other kinds of apps) have a few issues with the DWM in Vista. Not only do apps appear to be slower (there’s a noticable lag), the double buffering of the double buffered buffer has other issues as well. Like ghosted frames when the framebuffer isn´t completely redrawn with each frame update.

Instead of whining about how much Vista sucks, I´d like to do something about it, because the DWM isn´t going away. At least, I hope it´s not, because I think it´s rather nice to have a composited desktop.

I´ve been searching a bit on the interweb, but there´s very little information on how one would go to fix at least the “teh-app-is-lagging”-issue. Well yeah, I could disable desktop composition, but hey, I didn’t buy Windows Vista with its sexy composited desktop to disable it all the time, right? And so do most users, so disabling DWM to get ultra-responsiveness with my OpenGL app is not an option. Heck, I would boycot any program that would do so.

Anyway, it appears there are a bunch of DWM API functions that can be used to either give the application more CPU time, or specify how and when the DWM should do its thing. I’ve tried a bunch, but I’m probably doing something wrong because all the available structures return zeroes.

However, this isn’t the right forum for asking questions about the DWM API. What I was about to ask: before I dive into this, are there any people out there who have done such research themselves already? Are there people who already know how to make DWM-ed OpenGL apps more responsive, in any way?

And also (hence the reason for not posting it in the OpenGL-on-Windows subforum), how are issues like these handled on other platforms? How do apps on OS X get along with the composition manager? How do they get along on Linux/BSD with Compiz Fusion? Is the compositing done differently in those environments, or are they having the same issues as there are on Vista/DWM?

But most importantly: does anyone have any idea how these compositing managers can be controlled to work nicely together with OpenGL apps? Because I’m really pulling out my hair on this one. One the one hand, I’d like to have a sexy desktop, but on the other hand I’d really like to have a responsive OpenGL app.

I can only confirm that there’s a lag with OpenGL apps with Compiz Fusion enabled on Linux (ubuntu).

N.

Apparently we have to accept a 10-12% performance hit with GL and Vista, plus you can only get quad buffered stereo in fullscreen mode. This is why we don’t support it, and so far that hasn’t been a problem in the visualisation industry…nobody seems to want to touch it with a 10 foot barge pole.
Irrelevant to the thread, but I installed Vista when it first came out, and for the first time with an MS OS, I uninstalled it. I may give it another try when the SP comes out, but I don’t hold up much hope for any miracles. It’s a broken piece of crap, don’t waste another minute worrying about it - you can bet your boots MS won’t.

The performance hit on WDM isn’t really that bad anymore, by the way. For my app, running on a GeForce 8600GT (mobile) and up to date drivers, it’s at most 5% slower.

And well, -NiCo- kind of confirmed what I was “hoping” for. Vista may not be great at all areas, but we’re talking about the composite manager here, which seems to be giving problems on other platforms as well. So what can be done to improve that, and make OpenGL apps without the lag?

That’s what I wrote this topic for, because it seems to be an issue that’s going to pester a lot more people than just those who use Vista.

Don’t sugar coat it, knack… tell us what you really think

Yep, nothing is free. All that extra glitz and glamor doesn’t come without a price. Depends on what it’s worth to you to see your favorite application magically fade into the background on exit, or watch your desktop clock tick through a translucent window (god help me I do love that so).

I’m secretly hoping that the Vista SP1 allows a developer to turn off the compositing on a per window basis - and avoid the copy. I don’t see why not, just let an app deal with the good ole’ WM_PAINT messages again when a window is revealed. Seeing as EVERY app that has to support XP does this anyway (i.e. 100% of all software!).

I’m not holding my breath though…

Per window ? I am pretty sure it would not help performance in any way.
Think about it, with an hardware accelerated compositor :

• every window has to be stored as a distinct texture
• every window update means an update of the texture
• actually seeing/compositing the said windows means drawing some quads
• so even if you could turn off compositing for “your” gl window, everything else has still to go the composite route, so you compete for hardware resources -> perf penalty

Please correct if I am wrong :

• the current status is that both framerate is a bit lower and time to see the updated frame is longer (lag) ?

What about Direct3D applications? What if you turn off Aero?
I have been turned off my Vista. Windows explorer is weird. They have made lots of unecessary changes to the control panel.
I do like that Aero look. It makes moving windows more fun.

i personnaly do not have a problem with a ~5% performance drop in windowed applications, but the lag is what bugs me. i tried turning of aero (to windows classic mode) but it did not feel as responsive as xp, so i still felt some lag…

the problem is that aero is running with vsync which can not be turned off. so OpenGL is rendering at full speed into the internal aero double buffer which is swapped multiple times for one aero frame. i do not know what to expect if the vsync can be turned off. the lag would still be there but i am not sure how the tearing artifacts would look like.

is the compositing manager in fullscreen applications still enabled? i do not think so. so fullscreen applications should not show the lag.

i tried aiglx/compiz on linux and it felt different, there was a lag but i am not sure what was different. i think there was no vsync on the desktop compositor…

i too like the composited desktop, but i hate laggy applications.

p.s. does anyone have some experience with windowed D3D applications under aero?

Yeah, that’s pretty much the problem here.

What I think we need to fix this is some kind of synchronisation with the composite managers, because it’s not the speed or vsync that’s an issue here, it’s the (seemingly) random updates to the screen at the wrong times.

I’ve read everything about the DWM API that comes with Vista (dunno about Compiz Fusion or OS X, unfortunately) and it looks like there should be a way to do what I described above, because their very own Windows Media Player does something to “align” updates with the compisitor as well, and I keep seeing messages from MS developers who say there’s a bunch of functions to schedule things correctly. But how to do that… there’s very little information available about such things, even @ MSDN. And how would one do something comparable for other compisitors…

I don’t program with D3D, but I did find a D3D sample program that can render directly into the compositor surface (at least, that’s what it looks like, 3d objects composited on top of the desktop in realtime). I can’t remember the link anymore but it was somewhere @ the CodeProject.com

I’ll try to modify that app to use OpenGL instead, it looks very interesting to me to have the ability to render directly to the composited surface.

For me it’s as responsive as on XP, but for some reason there’s indeed lag when I maximize my OpenGL windows. Odd.

is the compositing manager in fullscreen applications still enabled? i do not think so. so fullscreen applications should not show the lag.

As far as I know it should be disabled in fullscreen apps, but there are people out there writing other kinds of apps than games

Switching off the compositor is not a solution for windowed apps because all OpenGL (or D3D) windows wouldn’t be integrated in the rest of the desktop anymore (ie. when doing the Flip/Flip3D thingy, the live previews, etc).

p.s. does anyone have some experience with windowed D3D applications under aero?

I’m going to give it a try this afternoon, but I’m afraid it won’t be much better than the OpenGL case.

i just tested it again with the windows classic manager. the desktop shows tearing artifacts as expected, BUT the OpenGL application output was still synchronized although it rendered as fast as it can (so the app itself was not vsynced). really strange. because of this it still feals laggy and jumpy :/.

As far as I know it should be disabled in fullscreen apps, but there are people out there writing other kinds of apps than games

same here

Unfortuately it appears you can’t do this with OpenGL due to how the context interacts with the DWM stuff and how D3D interacts with it; it appears to require some D3D voodoo in order for it to work, trying the same thing with OpenGL just results in a normal back ground with no transparancy.

I’m at work atm so I don’t have the codeproject link handy, but I seem to recall it relying on the PresentEx() for said voodoo to work.

You’re right, it doesn’t work But it wasn’t really important anyway.

My current findings are that both OpenGL and Direct3D under Vista/DWM are suffering from the lagging issues. You can even see it happening when you keep updating a window while moving it around (with the mouse). The window will lag behind the mouse, just like the lag inside the window at other times. Again, that’s for both GL and D3D.

Well, after playing around a bit more, I’ve found that the DwmSetPresentParameters function can help somewhat to remove a fraction of the lagging. Also, it makes window-dragging on windows with constantly updating 3d content a lot smoother, without any lag at all (while it does lag without calling this afore mentioned function). The 3d content seems to be a bit faster too, altough still a bit laggy and not perfect, and “feels” better.

If someone else would like to try, you can use the following DWM_PRESENT_PARAMETERS structure to get the same results:

DWM_PRESENT_PARAMETERS dpp;
memset(&dpp, 0, sizeof(dpp));
dpp.cbSize = sizeof(dpp);
dpp.fQueue = true;
dpp.cBuffer = 8;
dpp.fUseSourceRate = false;
dpp.cRefreshesPerFrame = 1;
dpp.eSampling = DWM_SOURCE_FRAME_SAMPLING_POINT;
HRESULT hr = DwmSetPresentParameters(hWnd, &dpp);

(don’t forget to include dwmapi.h and link with dwmapi.lib)

I guess one could go pretty far in making things feel less laggy when used in combination with the timing information from the DWM (see the DWM API documentation at MSDN).

So, until that’s figured out the question is: how can something comparable be done for Compiz Fusion and on OSX (if it’s got the same issues) as well?

But I guess that’s really not ontopic for these boards anymore, so I’ll ask at the Compiz forum later…

Could you inform us about your future findings? I am very interested in this topic too…

I’ll second that…

Sure, no problem. The more information available about this, the better

I’ve added a frame counter to my little testing app and discovered the reason for why that what I mentioned above is faster: normally, the rate at which the window is being updated is (supposed to be) the same as the monitor refresh rate (or compositing rate, but both comp and monitor rate are the same here).

On my LCD display, that’s a rate of 60 frames per second. When I do what I mentioned in my previous post, it goes up to 120 on my system. The DWM tells me the compositing rate stays at 60 though, which makes sense because the vsync is still on (altough switched off in my driver settings… pah, does anyones head hurt already?).

I’ve also found that 3 buffers (see the cBuffer variable) are enough to get that as a result.

Anyway, I’m afraid that’s all not really useful to know, because of this: When one assumes that SwapBuffers does not return immediately when things are yet to be rendered there’s no valid way to use the timing information from the DWM to keep things in sync with the compositor.
(I’m not sure about that as I’m quite new to OpenGL. Please correct me if I’m wrong)

That brings us to another (last) way to do it: locking the frame rate of the 3d view (wether it’s OpenGL or D3D doesn’t matter) and specify a source frame rate using the DwmSetPresentParameters function.

I hope I’m making any sense here. Some of it is still speculation. When I’ve got some time to spend I’ll try to use that locking approach. Microsoft appears to be using it to play video at correct video/compo-rates, so I guess it should work?

yeah me too, let us know when you’ve done all the hard work and tell us the answer
I may install vista again…shudder

Well, new findings today, not sure if I’m all too happy about that.

I’ve been mostly testing with D3D yesterday, and the DWM API truely did help to remove part of the lagging.

But, what I’ve found today, is that OpenGL is faster by default (without tinckering with the DWM), but gets slower when trying to do modify the presentation settings. It’s a lot slower, actually. Frame rates of 120 go down to 20, not nice.

D3D is slower by default, but feels faster when the DWM stuff is used.
OpenGL is faster by default, but becomes terribly slow when the DWM stuff is used.

I suspect it has something to do with the rendering into the shared surface by D3D, but again, I really can’t be sure about that. It’s only an observation and a thought, mostly because I think the buffer could be copied around too much when using OpenGL and additional DWM buffers (or perhaps it tries to copy data directly from the vram instead of a surface in system memory? I have no clue…).

The search for responsiveness continues…

I’m (temporary at least) about to give up for a while.

I’ve been working on it for almost 3 full days and 2 days partly now, and to get it working (or what I think should make it working nicely) one needs to be an expert (or at least pretty good) with large resolution timers and large numbers (think uint64’s), which I’m not yet, unfortunately. My large numbers explode right in my face, for some reason.

Also, I’m out of free time at the moment.

If anyone out there visiting this forum is an expert at those things, I’d like to ask him or her to give it a look. All the variables from the DWM structs are just numbers and derivates from QueryPerformanceCounter counts and most of them are general numbers, meaning that they are numbers from the DWM, not the specific application that queries the information.

I might come back at it at some point (I’m going to need advanced time management for my app), but that’s definitely going to take a long while before it happens, as there’s plenty of other work to do first.

I’m sorry for those who expected to see a quick answer, but I do sincerely hope that this topic will inspire someone else to take a jab at it, or discuss other ways to get 3d apps using the DWM not only smooth but responsive as well, without directly synching the update rate of the application to the composition rate and having the need to do all the hard timing work yourself.