¶Is it too much to ask to have ONE good image display API in Windows?

Lately, I've been becoming increasingly frustrated with how difficult it is in Windows to reliably and efficiently blit an image to the screen with high quality. It shouldn't be that hard, but it is, because there are half a dozen different ways to do so and none of them meet all of the requirements. So I sat down and made a table of all of the ways to blit an image to the screen in Windows, and how they all suck in some fashion.

VirtualDub has code paths for GDI, DirectDraw blit, DirectDraw overlay, Direct3D, and OpenGL. GDI+ is here because it looks like a good API, until you discover that it has no useful hardware acceleration, has incorrect subpixel positioning for image blits, and is no longer being evolved. I put WPF (Avalon) here because I looked into it as a possible alternative when operating under DWM composition / Aero Glass on Vista, which is problematic since neither GDI nor DirectDraw are accelerated, and Direct3D in child windows seems very flaky. The huge problem with WPF is that it requires .NET managed code, since the API is in .NET and the underlying MIL API isn't documented (grumble); another problem is that it seems unusually slow and flickers a lot whenever windows are resized.

Anyway, the table of image blitting woe:

Explanations:

• sw: Supported, but with software emulation only.
• Platform support: Versions of Windows on which this API is available, including ones for which a redistributable is required.
• Requires managed code: Whether this API can only be used from .NET managed code.
• Hardware acceleration w/o 3D HW: Whether this API can be accelerated with older graphics hardware that only supports 2D acceleration.
• Hardware acceleration with 3D HW: Whether this API can be accelerated on 3D-capable hardware.
• Software fallback: If operation is possible without hardware support.
• Works with DWM composition: Operation when DWM composition (Aero Glass) is active under Windows Vista.
• Bilinear filtering: If bilinear filtering (4 tap) is supported on stretched images.
• Bicubic filtering: If bicubic filtering (16 tap) is supported on stretched images.
• Terminal Services: Whether the API works over Terminal Services (Remote Desktop) is active.
• Supports 256 color display: If operation is possible on a paletted display.
• RGB color conversion: If display of an RGB image in a different format than the display buffer is supported.
• YCbCr color conversion: If display of a YCbCr-encoded image is supported.
• Beam detection: If the API supports reading the position of the display image scanning beam.
• Beam avoidance (vsync): If the API supports altering the timing of image display to avoid tearing.

Notes:

1. Requires redistributable prior to Windows XP.
2. Requires redistributable for Windows 95.
3. With RGBRast. (Refrast is not counted as it requires the SDK and is excruciatingly slow.)
4. Microsoft's OpenGL 1.1 software implementation is available, but it is very slow.
5. Not supported. Overlay creation succeeds, but the overlay never shows up.
6. DirectDraw blits are point-sampled when DWM composition (Aero Glass) is active. Otherwise, filtering is up to the driver.
7. Varies widely; some drivers don't interpolate vertically, and some only interpolate chroma.
8. Requires custom implementation.
9. Can be hardware accelerated between two Vista-based systems using Avalon Remoting.
10. RGB overlays are possible, but I've never seen hardware that supported it.
11. Automatic if DWM composition (Aero Glass) is enabled.
12. Requires redistributable.
13. Requires Windows NT; quite slow.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.