次の方法で共有

Responding to Comments from "Under the Hood of the DWM"

  • [アーティクル]

Wow... lots of great interest and comments in my previous post on "Under the Hood of the Desktop Window Manager".  Rather than attempting to comment inline, I figured I'd try to address in a separate post.  So here goes:

Anonymous:I'd like to know why DWM can't just use the alpha channel of the buffer that Avalon draws to, to be able to do completely hardware accelerated irregular shaped and alpha blended windows, but instead has to drop Avalon HW acceleration and go to software rendering...

The above is not the case, if I'm parsing correctly.  An Avalon application is effectively a DirectX application, and renders to a DirectX surface.  This can be a video memory, hardware accelerated surface, and its display through the DWM does not require that it be booted out to software.

Stephane Rodriguez: "Tear free experience"
How is this possible? Doesn't this depend on how much is getting drawn?
Two decades ago, on machines like Atari ST and Amiga, it was all about the vertical blank. People used to write applications (demo) that would draw based on the vertical blank frequency, avoid the drawing spot, resulting in smooth scrollers and so on. Whatever happened to this?
In other words, I don't think the tear experience scales well if you drawing too much on the screen at the same time, say you are running a couple videos concurrently.
And I still fail to see how tear-free experience will make mom and dad feel excited about Windows Vista. Sorry, it had to be said.

Today's "tear free" isn't the old Atari/Amiga approach which as you say tried to fit everything into vblank.  Instead, DirectX is able to maintain a "flip chain" of buffers and swap between them for what's displayed on the screen.  The "flip" happens at a very low level in the system and does occur during vblank.  But it doesn't require drawing.  The video card then simply scans out the new front buffer, and treats the old front buffer as the back buffer that the application (in this case the DWM) renders into. 

Tear-free making Mom & Dad excited about Windows Vista?  Yea, can't help you much there :-), but hopefully the accumulation of all the good stuff across Vista will be enough.

[3/18/06 - Update - tear-free exciting Mom&Dad. It occurs to me that I may have been too flip in this response. Tear-free on it's own won't excite them, however, this is just one of the many quality improvements being made where the sum of which will lead to just a better, more solid feeling product. Kam VedBrat also talks about this effect.]

JoeW: I would like to know more about the public APIs. Specifically I would like to know how Vista's native dialog boxes are rendered (message box, explorer windows etc). Do they still use GDI or do they use an unmanaged composition engine?

More on the public APIs in a later posting.  However, regarding how dialog boxes are rendered, there's fundamentally no change here.  GDI is still used, and the windows redirect through the DWM just like any other GDI application.  The primary rendering that the DWM itself is responsible for is the non-client areas of windows.

David Larsson comments on issues he's hitting with High DPI mode in the latest Vista CTP.  I can say that many of those rough edges are being addressed.

Another David asks about memory requirements for DWM given that windows contents are stored.  It's definitely the case that there is a larger memory requirement when running the DWM -- but rather than getting further into it, I do expect that to be discussed in a future posting.

Shawn Oster: As I'm reading a few dozen questions come to mind. You hit on some of them in your "upcoming topics" hit list but here are the things that sparked:
1. How signifigant will hardware acceleration be to Glass? It used to be there was the 2D benchmarks for work apps then the 3D benchmark for the fun things. An amazing game card would often be horrible at having a lot of small Excel/Word/Visual Studio windows open.
2. One of the first things new developers learn is to do their own screen buffering, to a bitmap, metafile, etc. Does the DWM change that since it's already buffering?
3. What kind of impact will this have on apps like Photoshop? Are there things raster image editing programs can do to improve speed if they are running on Vista?
4. If you are running old hardward does everything still go through the DWM? Like inside a Virtual PC?
5. How much control will we have over DWM? For example could someone create Flip/Flip3D as a stand-alone app? The nerdling fun side of my brain imagines interfaces a la Minority Report (minus the gloves and Tom Cruise).
6. Hmm, speaking of the Minority Report UI, how well will video drag?
7. How heavy a load does DWM put on the system? I remember when shell replacements were big (LiteStep, geoShell, Cloud9, etc) and the goal was always reducing load while giving UI goodness. Sounds like DWM could be that as long as it isn't seen as a boat anchor.
Looking forward to more blog posts on this subject. Try to come up for air just a wee bit more often :)
 

and answers to those...

  1. HW acceleration is a very significant determinant of DWM performance.  Particularly video memory transfer rate.  Windows Vista will enable the DWM on hardware that's capable of supporting it, and we do expect that to be a wide range of hardware.
  2. Application doing screen buffering: I'll address that further down in response to another person's question.
  3. The DWM itself doesn't really have substantial impact on apps like Photoshop (other than the buffering issues).  There may be other Vista advice they can follow, but I don't have that.
  4. Things will go through the DWM if the hardware qualifies, including being sure that a Vista Display Driver Model class graphics hardware is in use.  More on that in a future post.
  5. More on that in a discussion on DWM APIs
  6. I assume you're referring to the issue on XP and before that when you drag a window with video, the video lags the window.  That's because in those systems, hardware overlays are being used.  In Vista, the window is composited, and everything is in sync, so no more lag.
  7. We're working hard to be sure that the DWM doesn't put an overly hefty load on the systems that qualify for DWM.

 

DCMonkey asks about resize semantics under the DWM.  This is something we're working on improving, and have made good progress there.

Kirill Osenkov asks: Does it mean I should get rid of my (now unnecessary) custom back buffer when I port my app to Vista? Does it also mean that all flickering applications will automatically become flicker-free?

Yes and No.  Applications no longer need to double buffer when the DWM is running provided that their purpose in double buffering was to avoid video-system induced tearing.  However, double buffering is also frequently used by applications to avoid "structural tearing" -- for instance, being sure that this triangle and this rectangle are presented atomically.  This is not something that the DWM can help with.  So it really depends on your usage of double buffering, and your original source of flickering.  Each application author is going to need to evaluate that for themselves.

HTK asks whether the first screenshot with the bigger buttons is a real screenshot.  No, it's not, sorry I wasn't more clear.  That was really intended to show the design element/sensibility for Aero.  All the other Windows Vista images are screenshots.

Chris Nahr asks about getting rid of traditional WM_PAINT processing altogether, and just drawing new elements as required.  This is absolutely not the direction that this is going.  WM_PAINT is still used in many places throughout the system for invalidation and rendering requests of client areas.  Chris also asked about higher resolutions.  That'll be covered in a future post on high DPI support.

ion and other asked about jaggies/aliasing in Flip3D.  Yes, this is certainly a known issue that we're actively working on addressing.

Eli asks about glass blurring, and DWM accelerating GDI.  Pixel shaders are indeed used for the blurring component of the "glass" look.  And DWM does not accelerate GDI rendering.  However, due to the nature of desktop composition, operations like window moves and resizes can be faster/more responsive because underlying content need not be re-rendered.

Anonymous asks about text rendering.  The caption area text rendering is going through the same text rendering that WPF uses, and thus is subpixel ClearType.  Furthermore, there is an exposed API in the theming DLL for rendering text atop "client area glass" -- more on that in a future post.

ping pong asks if DWM is written in a managed language.  It is not.  It uses the same unmanaged rendering component that the WPF/Avalon system does.

Mike Dimmick talks about running Java applets in Sun's JRE results in the DWM being disabled.  Yes, Sun is well aware of this and is proactively working on a fix.  And you're right, that locking the DirectDraw primary surface has this result, since the desktop now needs exclusive access to the DDraw primary for the DWM to work.

DGC asks about memory usage.  Yes, there is a larger memory footprint with the DWM.  More on that in a future post.

KJK::Hyperion asks about total abuse of this technology through 3rd party programmability.  But of course ☺.  We do have a certain amount of programmability of various key features like glass, thumbnails, and control of composition.  More on that in a future post.

Keith Patrick and MueMeister both wonder about the relationship between DWM and WPF, and if there is any.  There most definitely is a big relationship.  Both DWM and WPF are written on the same unmanaged rendering layer that sits above DirectX and is responsible for all the actual rendering in both WPF and DWM.

Comments

  • Anonymous
    March 10, 2006

    "Instead, DirectX is able to maintain a "flip chain" of buffers and swap between them for what's displayed on the screen.  The "flip" happens at a very low level in the system and does occur during vblank.  But it doesn't require drawing."

    Thanks for your answer. What you describe here is what we used to do back in the old days : we had a bunch of back buffers and we would blit them back and forth (with the help of marvelous blitter and copper chips on the Amiga for instance). Up until we would reach the actual desktop buffer. Thing is, when drawing on the desktop buffer itself, we wouldn't blip the entire screen from back buffers, but restrict to portions, hence the "let's avoid the drawing spot" craze. The only limiting factor at the time was how many large blits we'd be able to do in a VBL. From what I understand, there is nothing really new, just that the resolution is bigger now and the processing power has dramatically improved. The Atari/Amiga were on the 7MHz CPU range.

  • Anonymous
    March 11, 2006
    Ah, sounds good. I got the impression from another blog post by some other 'softie, can't find it now, that as soon as an Avalon window started using per-pixel transparency, it's internal drawing would no longer be hardware accelerated at all.

  • Anonymous
    March 11, 2006
    Грег Сшечтер отвечает на вопросы по своей краеугольной статье о DWM. Пожалуй, да

  • Anonymous
    March 11, 2006
    I read and participate in newsgroups (and blogs) regularly.  This entry is derived from a recent long post of mine in response to some very passionate newsgroup posts by some folks using the latest Windows Vista CTP

    The are a number of very positive

  • Anonymous
    March 12, 2006
    I can accept the Amiga/Atari similarities and those are fine.

    However, whatever the software/hardware approach may be the finesse, in my opinion, is in the construction.  These are neat with a very fine construction and effective use of z-stacking effects.

  • Anonymous
    March 12, 2006
    Greg's started a great converation on his blog about the internals of the DWM.
    I want to take a second...

  • Anonymous
    March 13, 2006
    This has been a great blog entry Greg.  I have a couple of questions that I would love to see answered.

    1. Do you know of a solution to the mirror driver vs. compositing engine problem?  To recap it, the mirror driver has been an excellent method of getting screen contents in an efficient manner, however, in Vista a mirror driver will force the compositing engine to turn off.  Has there been a method identified to get the composited screen contents back from the video hardware in an efficient way?

    2. Is there an API to get the contents of windows belonging to a specific application (either before or after the composition engine takes it for its magic carpet ride)?  Furthermore is there a way to get those contents AND the surrounding window frame?

    Thanks Greg.  I'm looking forward to more great info on DWM and the reworked Graphics/Video pipeline.

  • Anonymous
    March 15, 2006
    Greg,

    I really liked your talk at the PDC (a late compliment, I know!) That 15 puzzle demo just blew me away. Anyway, here's my real comment:

    I noticed that the DWM sometimes gets turned off, so that the "Glass" experience is disabled. Under what circumstances does this happen? How does Vista detect that the DWM needs to be turned off?

    I noticed this happening when running iTunes 6.0.2.23 and QuickTime Player 7.0.4.

    Any comments?

  • Anonymous
    March 16, 2006
    Oluf,

    I noticed the iTunes/QuickTime badness recently as well.  I'm not sure, but my uninformed guess is that Apple is using DirectDraw to draw their iTunes window.  Use of DirectDraw will disable desktop composition.  I also assume that Apple is planning on fixing this.

    I'm sure Greg can elaborate on the conditions that turn off the composition engine.  At least the OS autodetects when it is safe to reenable.

    Michael Price

  • Anonymous
    March 19, 2006
    "2. Is there an API to get the contents of windows belonging to a specific application (either before or after the composition engine takes it for its magic carpet ride)?"

    PrintWindow(), WM_PRINT and/or WM_PRINTCLIENT may be what you're looking for.  Not sure whether they can include the DWM-rendered window frame.

  • Anonymous
    April 05, 2006
    Stephane,

    What occurs is actually a lot faster than blitting a back buffer to the front buffer during vblank.  All modern graphics cards simply use a pointer to the current front buffer, so "flipping" is as easy as changing a register in the graphics card.  Then the hardware that reads pixel values and sends them to the DACs (for analog RGB) or to the digital DVI just reads pixels from a different memory location.

  • Anonymous
    April 05, 2006
    > I assume you're referring to the issue on XP
    > and before that when you drag a window with
    > video, the video lags the window.  That's
    > because in those systems, hardware overlays are
    > being used.  In Vista, the window is
    > composited, and everything is in sync, so no
    > more lag.

    I hope overlays are still an option. Every other method to playback videos increases CPU usage brutally - up to the point where most CPU is spent on that. I can do 1280x720 with overlays, but only 640x480 without, even using hardware colorspace conversion and resizing. For example VMR9 is "bad" - very bad for me. I don't care about the glitches - I know where they come from, no problem.

  • Anonymous
    April 20, 2006
    Here's a list of topics that I have posted on (with active links) or expect to post on (without links)...

  • Anonymous
    June 07, 2006
    When talking about WPF during the Windows Vista ISV Touchdown training a lot of people were interested...

  • Anonymous
    May 31, 2007
    When talking about WPF during the Windows Vista ISV Touchdown training a lot of people were interested

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/4483729-there-is-no-net-in/2

  • Anonymous
    May 31, 2009
    PingBack from http://woodtvstand.info/story.php?id=6527