USER & GDI Compat, part 2 -- Performance

Thanks for the comments on the last post, here's part 2 of roughly 5.

We think most applications will run as fast or faster on Windows Vista, but there are some changes we want to keep an eye on.  Please be on the lookout for:

• Overall GDI drawing performance is slower? -- GDI primitives like LineTo and Rectangle are now rendered in software rather than video hardware, which greatly simplifies the display drivers.  We don't think this will impact many real-world applications (usually when a GDI application is render bound its because it's doing something like gradients that was never hardware accelerated), but if you do see problems please let us know.
• Slower text rendering? -- We changed calls like DrawText to better support international and East Asian languages, we don't think this will impact real world applications but want your feedback if it does.
• Reading from and writing to GetDC(NULL)? -- this operation is slower than previous versions of Windows because applications now render to an offscreen bitmap rather than directly to the screen.  Where possible, consider drawing to an HDC backed by your HWND, or creating overlay windows.  GetDC(NULL) is still the preferred way to get a screen snapshot.
• Reduced application address space? -- the bitmap for a top-level window is stored in the application's address space (see previous post), potentially reducing available address space by a few megabytes.

Next up: high dpi

Comments

• Anonymous
  April 13, 2006
  Sorry for commenting so late, I just found your nice blog.
  
  I have two related questions:
  
  1. In earlier versions of Windows, applications only needed to draw the visible part of their windows, which enhances performance for large windows that are only partially visible. Will this be changed with Windows Vista?
  
  2. I wrote an application that sometimes creates huge top level windows (e.g. 50000x50000 pixels) to reflect the zoom level selected by the user. These windows can hardly be buffered in memory. Will such windows still work in Windows Vista?

• Anonymous
  April 16, 2006
  How much has the GDI software implementation been updated? StretchBlt() was always very slow when emulated by GDI in earlier versions of Windows, but it seems to have improved by an order of magnitude in Vista.
  
  

• Anonymous
  April 17, 2006
  Phaeron -- That's interesting, we haven't intentionally done anything to StretchBlt() to make it faster, I guess it could be something we changed for unrelated reasons.  We've optimized some of the clipping logic, so if your StretchBlt wasn't actually getting displayed, that might be it.  Another possibility is that because the bitmap is now completely in main memory rather than video memory, there's less bus traffic.

• Anonymous
  April 17, 2006
  Robert -- Thanks for the feedback.
  
  1. You should paint the region that Windows asks you to paint (GetUpdateRect et al).  In earlier versions of Windows, you'll only be asked for parts of the window that are visible on the screen, but in Windows Vista we'll ask for the entire application.  (That also means it's not usually worth doing a lot of work in your WM_PAINT to decide which parts of the hwnd need painting and which don't)
  
  2. I don't know.  We handle windows that are bigger than the video card's maximum texture size, but we haven't done much testing at 50,000x50,000 pixels...
  

• Anonymous
  April 24, 2006
  This content will make it into the master compatibility document in the next month or so, but in the...

• Anonymous
  December 01, 2007
  PingBack from http://www.itwriting.com/blog/?p=430

• Anonymous
  January 01, 2008
  Begonnen hat das neue Jahr 'suboptimal'. Eigentlich sollte die Speed-Runde II nach einer 24stündigen Pause pünktlich um 18 Uhr fortgeführt werden, nur leider hatte ich den Termin verschlafen. Gestartet wurde das Spiel dann um 19 Uhr, aller