Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ UI rendering in Windows 7

I spent some time downloading and Windows 7 RC today. I installed the beta a while ago, but didn't do too much with it since I had only installed it on a VM, which invalidated any comparisons in graphics performance and prevented any access to 3D acceleration. Well, this time I took advantage of the uber-cool install to VHD feature to install and run Windows 7 without having to repartition my hard drive, so that I could run it directly on real hardware. I get the feeling that I'm pretty far behind in noticing some of the improvements in Windows 7, but hey... better late than never.

Now, to understand where I'm coming from, I've had both 32-bit XP and 64-bit Vista installed on dual-boot for some time, but I almost never boot into Vista 64 unless I need to test some 64-bit code. The reason is that Vista 64 runs like complete crap. CPU and memory aren't a problem, because I have a 2.5GHz Core 2 and 2GB of RAM. The problem is my somewhat mediocre NVIDIA Quadro NVS 140M, which is 8400GS based, compounded by my 1920x1200 display. It runs like a slug with Aero Glass enabled, and is still laggy and runs at low frame rates with it off. The result is that Visual Studio 2005 is noticeably more sluggish on Vista 64 than in XP, and thus I spend all my time in XP instead.

The main reason that Vista performs worse is that, despite all the hype about the new desktop hardware acceleration, the WDDM 1.0 display driver model introduced in Vista actually forces all GDI and DirectDraw rendering to occur in software on the CPU. Since most UI in Windows is based off one of those two APIs -- including Win32 UI and .NET's GDI+ based UI -- this results in significantly slower UI performance. Well, unfortunately, it doesn't seem that Windows 7 runs Aero Glass any better, and in fact on this system VirtualDub has trouble breaking around 25 fps due to the low desktop composition frame rate. It runs noticeably better with composition disabled however: stretching video to 1920x1200 through DirectDraw now takes about 0-2% of the CPU instead of 6-10%.

The reason for this, as it turns out, is that the new WDDM 1.1 DDI in Windows 7 reintroduces support for adds several GDI optimizations, including reducing lock contention and reintroducing some hardware acceleration. The DDI documentation for GDI hardware acceleration reveals seven primitive operations that are supported for acceleration: alpha blend, BitBlt, ClearType blend (text rendering), solid color rect fill, StretchBlt, and transparent blit (color key). That covers a lot, but the one notable omission is line draw. In theory it would be possible to accelerate those by rasterizing the line to spans, and it'd be trivial to do so for the common cases of horizontal and vertical lines, but I don't know if Windows 7 actually does this. In any case, reintroduction of basic GDI acceleration is welcome. This also appears to extend to DirectDraw blits, although those are still not bilinearly filtered as they usually are with XP drivers.

Another interesting change is that WDDM 1.1 reintroduces support for DirectDraw hardware video overlays. In Vista, attempting to use a hardware overlay either resulted in the overlay calls silently failing or desktop composition being forced off. It appears that overlays work again on Windows 7. You can't test this with current versions of VirtualDub since I added code to force them off on Windows Vista or later due to the poor OS behavior, but you can see them in action if you get an old version of VirtualDub like 1.6.0. They don't work quite like on XP, though, because for some reason they don't update except when a GDI repaint occurs. I'm not sure if it's worth investigating this since any video card that supports WDDM 1.1 supports DirectX 9, and at that point it's better just to use Direct3D.

I have noticed a couple of occasional weirdnesses in the USER layer in Windows 7 that I haven't pinned down yet. In the beta at high DPI, one specific item in VirtualDub's display pane context menu bizarrely shows up in a different font. Altirra also occasionally shows a vertically displaced window caption in one of its tool windows after a full-screen mode switch. I suppose it's possible that these are video driver related, as the WDDM 1.1 drivers are still very new.

In any case, since I don't intend to buy a new computer any time soon, it's looking like I might be leapfrogging Vista to Windows 7 as my main OS, now that some of the 2D performance gaffes are getting addressed.

Comments

Comments posted:


When you say "It appears that overlays work again on Windows 7.", did you mean anything relating to the overlay mixer as well?

checkers - 08 05 09 - 04:49


You're saying the WinAPI's "AlphaBlend" function will get hardware accelartion in Windows 7?

Right now I wrote my own function that's about 30% faster than AlphaBlend, but I'm on WinVista.

How much faster do you think it will be in Win7?

Blight - 08 05 09 - 12:01


I haven't checked whether DirectShow's Overlay Mixer works, but I wouldn't be surprised if it did given that video playback is the motivator for their return -- you know, overlays being more difficult to screen cap and all.

I expect AlphaBlend() into a screen DC to be MUCH faster than a CPU-based routine in Windows 7 with a WDDM 1.1 driver, for two reasons. The obvious one is that it is now hardware accelerated. The less obvious reason is that Microsoft also did this to lower DWM memory usage, and in doing so, got rid of the system memory backing surface that was used by Vista. Therefore, any CPU-based code that was locking the window surface to do CPU-based blending could run much slower again due to reading from video memory. I'm not sure if there is any legal way to do this other than GDI+. If you're doing alpha blending to an off-screen surface, then my guess is that it probably still won't be accelerated and your routine will still win.

Phaeron - 08 05 09 - 15:39


Hmm, curious. I did some more digging around with regard to the new overlay support, and it seems that Microsoft is actually planning to expose overlays to Direct3D9 (Ex?), which makes things interesting:
http://download.microsoft.com/download/5..

The DDI docs have reference to a D3DCAPS_OVERLAY flag:
http://msdn.microsoft.com/en-us/library/..

No sign of the user-side API for this, although the new FLIPEX presentation mode is already documented. I wonder if this stuff is making it to D3D10/11, too.

Phaeron - 08 05 09 - 16:31


Can you give us an idea when VirtualDub will be officially supported on Win 7 x64? The blurb about VirtualDub on your start page only mentions 32 bit 95/98/ME/NT4/2000/XP.

After running Win 7 since the Beta I can't ever imagine going back to Vista (and I really liked Vista) so skipping Vista is the right thing to do if you're running XP now.

Martin - 10 05 09 - 03:05


It'll be officially supported when Windows 7 is officially released... not that it matters much. As of right now, I don't know of any serious issues with running VirtualDub under Windows 7.

Phaeron - 10 05 09 - 04:16


I don't know how bad the 140M is, but from the specifications is shouldn't be really that slow.

Maybe you're bitten by the overly-aggressive powermizer functions in the nVidia drivers. Even when plugged in and using a performance power profile, a lot of driver versions set the clocks really slow (easily 4 times slower than usual) when on the desktop (no fullscreen 3D app, excluding the WDM of course).

You might try to go to HKLM/SYSTEM/CurrentControlSet/Control/Video/{uid}/0000 and set the following values:

PerfLevelSrc to 3322 (or to 2222 for maximum performence even on batteries)
PowerMizerDefault to 1
PowerMizerEnable to 0
PowerMizerLevel to 1
PowerMizerAC to 1

YMMV, it might make your machine explode (it doesn't disable thermal throttling though), backup first, etc...

> due to the low desktop composition frame rate

Do note that the DWM only redraws dirty areas between frames.

John - 16 05 09 - 12:21


Been there, done that, doesn't fix the problem.

It's definitely not a fill rate problem, because I can redraw the entire screen in bicubic at 60 fps with Direct3D. The problem seems to be more on the texture upload side.

Phaeron - 16 05 09 - 14:38


This is interesting. It seems that video overlay support is really back: http://msdn.microsoft.com/en-us/library/..).aspx

However it is not supported in a compatible manner for older applications which use DirectDraw. A friend of mine tested MPlayer with the directx renderer on Windows 7 RC and it did shut down desktop composition again, just like in Vista.

As far as I understand the new overlay support is connected to Direct3D 9 Ex, which is a post-XP specific extension present in Vista and 7. I was just interested if Microsoft made the old DirectDraw API "just work", but it seems they didn't. You have to use the new Direct3D Ex API. Do you think that there could be any theoretical advantage of using this overlay support instead of a simple Direct3D 9 surface for video playback? I'm considering to add this "new" overlay support in my direct3d renderer for MPlayer in the future.

Georgi Petrov (gogothebee) - 09 06 09 - 10:44


I was wondering where they buried the hardware overlay APIs. Why is it under Media Foundation instead of the DirectX SDK...?

I have Windows 7 RC installed on this machine and I can confirm that hardware overlays DO work with DirectDraw 3 APIs. I get DDERR_OUTOFCAPS if Aero is enabled, but it works fine in classic theme.

The main advantage of the overlay is that it can't be screen captured, but I suspect that the overlay might use less GPU resources and power than the shader hardware. At near full screen with high resolutions on a low-end video card, it uses a noticeable amount of GPU power to do color conversion in 3D. Otherwise, though, I don't see a whole lot of reason to use it if a D3D mode is already implemented. The problem with overlays is that there is a lot of variance in how the video drivers handle levels, filtering, etc. The D3D9Ex interfaces at least allow you to specify the exact color format, but that assumes that the video driver folks get it right....

Phaeron - 10 06 09 - 01:44


Thank you for your brilliant program, I was wondering if there any plan on hooking into the built-in codecs in Windows 7?

Mark Koops - 20 09 09 - 15:48


Hi!

I made DX engine for DX9 which renders both 2D and 3D. 2D functions like testured rectangle are for application gui. Everything works great on XP but in Windows 7 all 2D overlays are invisible. I use simple DrawPrimitiveUP without vertex shader.

Does anybody know why Windows7 with DirectX doesn't render 2D items?

Thanks

Bero

Bero - 24 06 10 - 23:51

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.