Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Five Things Every Win32 Developer Should Know

4,623 views

Published on

Published in: Technology

Five Things Every Win32 Developer Should Know

  1. 1. Five Things Every Win32Developer Should KnowRaymond Chen(raymondc@microsoft.com)FUN412Windows User ExperienceMicrosoft Corporation
  2. 2. Five Topics Performance What you learned in school is wrong Playing friendly with others User interface issues The many faces of large fonts Parent and owner windows (review) Asynchronous input and synchronized input
  3. 3. Community Resources At PDC Other talks FUN319: Power-Aware Applications (Thu 5:15pm – note room change) An important “tax” FUN421: Garbage Collection Inside Out (Fri 1pm) Memory from the managed perspective Fundamentals Track lounge I’ll be there all day today Ask The Experts: System Internals
  4. 4. Talks You May Have Missed(watch the DVD) FUN405: Programming with Concurrency, Part 2 The dangers of trying too hard FUN307: Test Automation and Accessibility
  5. 5. Community Resources After PDC MSDN dev center: http://msdn.microsoft.com/windowsxp/ Newsgroups: microsoft.public.win32.programmer.* Forums: forums.microsoft.com/msdn/ New forum category: Windows Vista Development Essays on Win32: http://blogs.msdn.com/oldnewthing
  6. 6. Five Topics Performance What you learned in school is wrong Playing friendly with others User interface issues The many faces of large fonts Parent and owner windows (review) Asynchronous input and synchronized input
  7. 7. Performance Bottlenecks CPU speed is no longer the limiting factor Latency is what kills you (May not be true but it’s “true enough”)
  8. 8. Typical Latencies WAN (1e9-2e9) Floppy, CD-ROM (1e9) LAN (1e7-1e8) Hard drive (1e7) Main memory (25-50) L2 cache (6-10) L1 cache (1-2) CPU (1)
  9. 9. Pointers Are Expensive Pointers by their nature point elsewhere Not in the same cache line Usually not even on the same page CPUs and OSs don’t predict pointers well It’s the page faults, stupid (especially at startup) The Common Language Runtime (CLR) knows this
  10. 10. O(n) Can Beat O(log n) How big is n anyway? A simple array maximizes value from each page fault (every byte is used) Also friendlier to cache lines and L2 Linked lists, binary trees cost the most (only a few bytes used) A factor of 100 is hard to overcome The CLR Base Class Library (BCL) knows this
  11. 11. Five Topics Performance What you learned in school is wrong Playing friendly with others User interface issues The many faces of large fonts Parent and owner windows (review) Asynchronous input and synchronized input
  12. 12. What If Two Programs Did This? You aren’t the only program running. We’re all in this together.
  13. 13. Polling Prevents CPU from sleeping, monitor from blanking, drive from spinning down, etc. Keeps pages present Effect is magnified on Terminal Servers
  14. 14. The Thread Pool Use WT_EXECUTELONGFUNCTION as necessary. Clean up behind yourself If you create windows, destroy them. If you initialize COM, uninitialize it. Don’t leave unfinished business ShellExecuteEx DDE (use SEE_MASK_FLAG_DDEWAIT) SendMessageCallback
  15. 15. Remote Desktop /Terminal Services Your video card is very slow Disable animations (SPI_GETxxxANIMATION) Suppress unnecessary background operations Very similar to power management
  16. 16. Adapt to Hardware Capabilities Scale features up or down based on hardware Don’t need to cater to baseline machine Set defaults intelligently New for Windows Vista™: IWinsat The mechanism Windows uses to decide whether to enable visual effects To appear in Beta 2 winsatfb@microsoft.com
  17. 17. Hardware Metrics Graphics capability Gaming capability System memory bandwidth Processor throughput Based on realistic computations Disk sequential read throughput Computed on first boot, on hardware change, and on demand (e.g. app setup) Calibrate against actual hardware
  18. 18. Five Topics Performance What you learned in school is wrong Playing friendly with others User interface issues The many faces of large fonts Parent and owner windows (review) Asynchronous input and synchronized input
  19. 19. The Many Faces Of LargeFonts Large font scheme High DPI
  20. 20. Large Font Scheme The size of screen elements Caption, menu, message box, status bar, icon labels No effect on anything else
  21. 21. High DPI Changes the mapping between point and pixels Affect all point-based computations (primarily fonts and consequently dialog boxes)
  22. 22. Visual Comparison
  23. 23. Bitmap Scaling In DialogsSS_BITMAP SS_BITMAP | SS_BITMAP | SS_REALSIZECONTROL SS_CENTERIMAGE No scaling Stretched Centered
  24. 24. Dealing With High DPI Font metrics scale non-linearly Visually inspect your dialogs Bitmaps need to be adjusted Author for common DPI (96, 120, 144, 192) Stretch or center static images if no perfect match available Stretching down is better than stretching up “High DPI is the new multimon”
  25. 25. High-DPI DevicesSony VAIO U71 Toshiba M200 IBM T221:• 6” • 12” • 24”• 800x600 • 1400x1050 • 3840x2400• ≈166 DPI • ≈144 DPI • ≈200 DPI• ≈US$2700 • ≈US$2400 • ≈US$8000 Source: PRS325: Windows Presentation Foundation ("Avalon"): Advanced Graphics (Part 1): “2D, 3D and Text”
  26. 26. High DPI In Windows Vista “Large font scheme” is gone DWM emulates 96 DPI by default Will stretch your output to actual DPI Opt out via SetProcessDPIAware (recommended, but requires thorough testing) Windows Presentation Foundation already designed to be DPI-agnostic pixel-based objects (bitmaps and videos mostly) still require attention
  27. 27. Guidance for Windows Vista™PRS319: Building Applications That Look Great in Windows Vista™ In room 152, next! New common controls (including Task Dialog) Client glass The Aero philosophy Designing for the new “look”
  28. 28. Five Topics Performance What you learned in school is wrong Playing friendly with others User interface issues The many faces of large fonts Parent and owner windows (review) Asynchronous input and synchronized input
  29. 29. Parents And Owners Child windows are constrained by their parent Ownership is a relationship among top-level windows Most window-creation functions take a “parent or owner, depending” parameter Other UI functions take an owner
  30. 30. Parent/Owner Confusion GetParent() returns parent or owner GetAncestor() is clearer Documentation often casual about distinction between parent and owner
  31. 31. Parent And Owner Diagrams Visual Window tree Desktop Desktopnotepad find notepad simple edit find edit OK edit OK edit simple Owner “tree” notepad simple find
  32. 32. Reparenting And Orphans Only top-level windows can be owners If you pass a child window as owner, its top-level parent is used instead Consequently, reparenting a child window abandons its owned windowsHWND SetWindowOwner(HWND hwnd, HWND hwndOwner){assert(!(GetWindowStyle(hwnd) & WS_CHILD));assert(!(GetWindowStyle(hwndOwner) & WS_CHILD));return (HWND)SetWindowLongPtr(hwnd, GWLP_HWNDPARENT, (LONG_PTR)hwndOwner);}
  33. 33. Pitfalls Of Ownership Multiple visible top-level unowned windows on a single thread = red flag Choosing a random window as owner is not a solution Cross-thread ownership leads to input synchronization
  34. 34. Five Topics Performance What you learned in school is wrong Playing friendly with others User interface issues The many faces of large fonts Parent and owner windows (review) Asynchronous input and synchronized input
  35. 35. 16-Bit: Synchronous Input Input is globally serialized Shared keyboard, mouse state One focus window, one active window, one capture, one caret, one input queue Changes to focus, etc. are synchronous
  36. 36. 32-Bit: Asynchronous Input Input is per-thread Separate keyboard, mouse state Each thread gets its own focus window, active window, capture, caret Changes to focus are asynchronous with respect to windows from other threads> as if it were the only thread in the system
  37. 37. AttachThreadInput Indicates that two threads want to return to the old 16-bit style of synchronized input Your fates are intertwined
  38. 38. Synchronous Focus A has focus, B calls SetFocus(hwndB) B must wait for A to release focus since input is now synchronous If A is hung, then B hangs too
  39. 39. Synchronous Input In the queue are two input messages, first a message for A, then a message for B. B calls GetMessage – sees message for A and says “I can’t process my input until A processes its input first” If A is hung, then B never processes input
  40. 40. The Life Of An Input Message Input Queue A Message Queue A Thread ARaw Input Input Queue B Message Queue B Thread B Message Queue C Thread C Input Queue C+D Message Queue D Thread D
  41. 41. Behind Your Back Owner/owned windows are implicitly attached Parent/child windows are implicitly attached Journal hooks are the wildcard
  42. 42. Dealing With Input Synchronization Keep slow operations off the UI thread Avoid cross-thread ownership Thread 1 Thread 1 Main window Thread 2 Main window Thread 2 Progress Progress Work Work Back to Back to normal normal Avoid Prefer
  43. 43. Final Notes Evaluation forms Fundamentals Track Lounge Ask the Experts Q&A
  44. 44. © 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

×