Your SlideShare is downloading. ×
Five Things Every Win32 Developer Should Know
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Five Things Every Win32 Developer Should Know

2,306
views

Published on

Published in: Technology

1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,306
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
1
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Five Things Every Win32Developer Should KnowRaymond Chen(raymondc@microsoft.com)FUN412Windows User ExperienceMicrosoft Corporation
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. What If Two Programs Did This? You aren’t the only program running. We’re all in this together.
  • 13. Polling Prevents CPU from sleeping, monitor from blanking, drive from spinning down, etc. Keeps pages present Effect is magnified on Terminal Servers
  • 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. Remote Desktop /Terminal Services Your video card is very slow Disable animations (SPI_GETxxxANIMATION) Suppress unnecessary background operations Very similar to power management
  • 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. 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. 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. The Many Faces Of LargeFonts Large font scheme High DPI
  • 20. Large Font Scheme The size of screen elements Caption, menu, message box, status bar, icon labels No effect on anything else
  • 21. High DPI Changes the mapping between point and pixels Affect all point-based computations (primarily fonts and consequently dialog boxes)
  • 22. Visual Comparison
  • 23. Bitmap Scaling In DialogsSS_BITMAP SS_BITMAP | SS_BITMAP | SS_REALSIZECONTROL SS_CENTERIMAGE No scaling Stretched Centered
  • 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. 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. 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. 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. 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. 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. Parent/Owner Confusion GetParent() returns parent or owner GetAncestor() is clearer Documentation often casual about distinction between parent and owner
  • 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. 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. 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. 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. 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. 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. AttachThreadInput Indicates that two threads want to return to the old 16-bit style of synchronized input Your fates are intertwined
  • 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. 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. 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. Behind Your Back Owner/owned windows are implicitly attached Parent/child windows are implicitly attached Journal hooks are the wildcard
  • 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. Final Notes Evaluation forms Fundamentals Track Lounge Ask the Experts Q&A
  • 44. © 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.