The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

OpenGL Controls and .NET

Hi all:

I am working on a project where we want implement general-purpose UI Controls that are capable of all sorts of heavy-duty graphics effects (i.e. animate, transition, gradient, shade, transparency, etc.).

I'm a bit late to the party, but the direction things have gone so far in the project is to use managed code to implement a single OpenGL context and to write a custom window manager, lightweight (windowless) Controls, event handling, etc. to do _everything_ inside that single OpenGL context.

While we are confident that OpenGL can do everything we need in terms of graphics, there has also been a lot of debate as to whether GDI/GDI+ (using native code) could do enough to get by, allowing us to use .NET Controls and avoiding having to build our own framework. The UI is almost all 2D, and the few 3D portions could probably be simulated in 2D well enough to get by.

My major concern is that writing a whole framework (largely in parallel with a small subset of .NET) is a task that will become much larger than it appears on the surface. Others vastly more knowledgeable than me seem to feel the same way:

I was hoping I could get some disinterested third-party comments from Joel's forum:
- Is it reasonable to write your own framework on a platform that provides .NET already?
- Is it worth the trouble to get general purpose access to OpenGL rendering? Would GDI suffice?
- Are there any hidden issues in either case (i.e. HWND limits, GDI object leakage)?

Larry Gadallah Send private email
Thursday, December 11, 2008
I think XAML as manifested via WPF can do everything you mentioned (gradients, animations, shading, etc)

One question - can OpenGL code receive user interaction (mouse-clicks, key-strokes, etc) and tie them to a graphical widget?  So if the user clicks on the OpenGL representation of a button, can the code easily receive that notification as coming from the button?
Thursday, December 11, 2008
Yes, the window manager intercepts user input events from the system and performs "hit detection" to determine which Control was in focus and dispatches the event to the Control in question.
Larry Gadallah Send private email
Thursday, December 11, 2008
It sounds like WPF is exactly what you need.
Chris Altmann
Thursday, December 11, 2008
Unfortunately, WPF is only available on Vista at the moment. I gather (from MS) that there are stubs for WPF calls in some (recent) variant of Windows Mobile and some variant of WPF (SilverLight or WPF/E) will be included in an upcoming version of Windows Mobile real soon now.

Thursday, December 11, 2008
WPF is avilable on Vista and XP with a DirectX 9 video card
Friday, December 12, 2008
WPF does not require a DirectX video card. It has a software fallback mechanism.

Saturday, December 13, 2008
>>WPF does not require a DirectX video card. It has a software fallback mechanism.

Ooooh, that's sure to be a winner!

Sunday, December 14, 2008
WPF works on XP, Vista, Windows Server 2003, and Windows Server 2008.

Monday, December 15, 2008
I see that I failed to mention that this project is for Windows Mobile. Alas, while MS keeps saying that WPF/E (a.k.a. Silverlight) will be available on WM 7 "real soon now", it hasn't happened yet.

We've had plenty of debate about simply building our own framework of windowless Controls that render using OpenGL, but I'm growing concerned that this approach is a really big job disguised as a small one.
Larry Gadallah Send private email
Tuesday, December 16, 2008
I did something similar on my product but using DirectX instead of OpenGL. I'd say as long as you're certain all you'll need is basic pushbuttons, checkboxes/radio buttons, maybe dropdown menus and one-line edit boxes, and maybe a dialog frame that contains controls and can be dragged around -- that much is "pretty straightforward."

The problem is if you realize later you really need tabs and multiple sheets for instance, or other types of controls, you can't just plop them in. But it's nice having full control over drawing and effects, and if you're doing framerate-sensitive graphics especially, it's nice having full control over your execution thread.

I did my GUI system with all of the above except sheets and tabs in about 3 weeks (full time), though already had a wrapper around my graphics library to create bitmaps, color them, stamp text on them, draw lines, etc. I figured I'd have to refactor it a lot but it held up over several years of continuing product evolution. Most the changes were overloading drawing code to add new button types like "glow" buttons or lit and unlit text.

You also need a text parser or other system to read in the controls' positions such as from a text file you can edit quickly (I used Visual Studio's dialog editor which saved it to a text .rc file which I parsed for control types, names and relative locations).
The only other programming issue I can think of I hadn't considered was you also need to notify your controls when they get and lose focus from mouse move -- so if you're holding down a pushbutton then drag the mouse off, the pushbutton has to go back up (or the drop-down list has to close).

Again just be sure the basic controls is all you'll need and it's not that difficult to build or maintain.
Tuesday, December 16, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz