Home Home Archives About red box
Username:
Password:
 
rssPopular Content

Filed Under Programming
digg WPF and the Future?
visits: 234 | score: 0.5 
posted by sysrpl on Thursday June 12, 2008 9:51 PM

First and bit of a rant ...

GDI+ is a complete failure. It is slow, uses software rendering (please don't mention Matrox, they aren't an option in 2008), and doesn't have an officially supported C interface.



Microsoft, as in the video above, please get serious and create a new hardware abstraction API for drawing graphics to replace the ancient GDI. Put it into the Platform SDK as a C interface and create some .NET wrappers for it. Use every means at your disposal to make damn sure hardware vendors provide accelerated drivers for it.

I know what you're going to say ... we've done that twice already (GDI+ and WPF) with the last two shipments of Windows, so the answer is NO!

Well sadly, in my opinion again, WPF is not the answer. Microsoft you missed the mark twice now. While .NET might be well suited for enterprise development, it is not a real choice for commercial software. Commercial applications (all of the many programs I depend on everyday such as Office, Photoshop, AutoCAD, Lightwave, Firefox, Textpad, and I could go on and on) are and will remain in the C/C++ realm. This goes doubly so for intensive graphics applications.

So unto WPF. WPF needlessly ties graphics programming to a tree model, where everything to be drawn is an object and added must be added to some kind of drawing surface collection. It's unintuitive, and step in the wrong direction.

I want a programming model which has been proven over time and has worked work well in the past. I expect a C style graphics API in the vein of ...

Surface.Line(Pen, 10.5, 23.25);

Rather than ...

Line.Stroke = Pen;
Line.StrokeThickness = 2;
Line.X1 = 0;
Line.Y1 = 0;
Line.X2 = 10.5;
Line.X2 = 23.25;
Surface.Add(Line);

What we need is more advanced hardware blitting with blend modes, direct access to graphics memory, fast and smooth hardware interpolation of image, stroke, and fill resizing with antiailising done in hardware. We want layered graphics output, hardware transforms, and polygon clipping with spline curves as polygon segments while preserving strokes and fills.

We don't need a high level markup interface to putting pixels on the screen. Leave the markup in a control, not in the API.

Microsoft, please give us a new solid graphics API and make sure hardware manufacturers support it this time.

print send topic Rate this article  

Title:

image link indent align right align middle align left quote underline bold code quote
Comment:

page generated in 0.078 seconds | last modified 1/10/2017 3:48 AM
none  none