odern computer hardware and powerful graphics cards, now found in even 'budget' systems, support a new level of rapid rendering of more high-level descriptions of objects and dynamic response to interaction with them. A variant of XML, XAML, has emerged as the Microsoft syntax for describing the form and visual state of controls and user interfaces, and the links to executable code that let users interact with them in an application.
The leaps-off-the-page benefit of vector-based controls is visually accurate scaling on a wide range of display devices. Graphic designers and developers may be able to interact in new ways that increase productivity when they can rapidly exchange interface design in the software development cycle.
At a hardware level, the Graphics Processing Units (GPU) found in today's video cards will handle vector-graphics processing now handled by the CPU in a way similar to the way games now offload texture mapping and 3d rendering into DirectX enabled video hardware. Although XAML simplifies describing the appearance of vector-based controls, it will remain just as difficult to implement the code-behind, the algorithms, the complex interactivity, linkage to external data sources that modern control consumers expect. But, the new technology is a huge win for developers because it potentially eliminates handling tedious low-level UI drawing and painting tasks that constrain productivity.
Early applications and development tools for creating vector-based controls and user interfaces are in developers' hands now: Microsoft's Windows Presentation Foundation (WPF) and WinFX technologies are in Beta 2, and Adobe's SVG initiative has been available (so far with modest adoption) for a while. Also, in my opinion, you can consider the widely adopted Flash technology to be a somewhat vector-based solution paired with a superb rendering engine.
As with all new technologies there are performance issues. In WPF/WinFX, the need to alternate rendering (between GDI+ in main memory on one hand, and DirectX in video-card GPU memory on the other) means application developers need to monitor how their complex controls or UI's may perform, particularly in the run-up period to Vista. For more information, monitor the WPF MS forum, searching for keywords such as "performance" and "DirectX." A developer friend of mine suggests that there are clipping problems in the first version of WinFX that can result in software rendering "slower than GDI+." He also suggests that complex visual effects, like gradients, must be rendered into textures inside the GPU, and that the transfer of these textures may become a bottleneck.
He comments, "It is not a true immediate mode API. So you cannot really optimize memory usage or buffering. Nor can you change the rendering at a low level, nor can you use a context dependent rendering optimization, or any kind of incremental change optimization."
Tim Cahill, on the team responsible for WPF performance issues, blogs regularly on these issues, and I strongly suggest you read the entry WPF Graphics Performance Q & A, in which he summarizes current performance issues and how they may affect different types of software applications, directly addressing concerns raised in the comments above.
Attention Graphically-impaired Software Developers!
Graphic designers today enjoy very highly-evolved vector drawing tools, like Illustrator, and also enjoy the integration of vectors into what were formerly raster-painting programs, like PhotoShop's paths and masks. Until now, Microsoft's developer tools for creating custom controls or user interfaces have required developers to deal explicitly with the low-level tasks of creating brushes, calculating clipping regions, and painting rectangles to get the really dazzling graphics effects that end-users of controls relisheven expect.
Very high-level graphics effects such as per-pixel alpha transparency are so difficult to achieve that it's taken a generation of graphic hackers (morphed into graphic designers known loosely as 'skinners') working with technology such as StarDock's WindowBlinds to show how it can be done. And (dare I say?) a generation of game-designers using DirectX to show how not to do it.
All that's about to change. Attention graphically-impaired developers! You will now luxuriate in luscious gradients dancing to your commands on the humblest of tiny controls; you will have glass edges per-pixel anti-aliased to the alpha of your choice. So goes the latest song.
The ubiquitous COM-based controls (TreeView, ListView, etc.) have caused developers from VB through .NET 2.0 to struggle with the same gnarly low-level problems, such as "How do you suppress that horizontal scrollbar from hell in the TreeView control?" Customizing and mastering these controls required developers to delve deep into Windows internals, learning about API calls, windows hooks, and massaging parameter types. In my humble opinion, the best WinHook will be the last of its kind, mounted in the Museum of Unnatural Programming to be gawked at by visiting schoolchildren.
Will advances in hardware capabilities, new vector-based tools for making controls and UIs, new higher-level ways of describing them, and new software IDEs for manipulating, designing, coding, and debugging them change the game for designers as well as programmers? Take your designer friend for a latte, and stay tuned.