What 2D GUI Foundation Do You Use? 331
Zmee writes "I am looking to build a 2D application for personal use and I will need to use a canvas to paint custom objects. I am trying to determine what foundation to use and have not located a good side-by-side comparison of the various flavors. For reference, I need the final application to work in Windows; Linux is preferred, but not required. I have looked at WPF, Qt, OpenGL, Tcl/Tk, Java's AWT, and others. I have little preference as to the language itself, but each of the tutorials appear to require significant time investment. As such, I am looking to see what the community uses and what seems to work for people prior to making that investment."
More information (Score:5, Insightful)
You haven't provided nearly enough information. Are you talking GUI interfaces, or rendering? If rendering, is it raster or vector? If vector, then what primitives do you need? Full SVG? Is this real-time, and if so, how many polygons / pixels do you need to push and at what minimum framerate?
As a totally shoot-from-the-hip, off-the-wall recommendation, I'd say OpenGL for portability, including support on iPhone / iPad / iPod touch. Note that you'll want to stick to the OpenGL ES subset in that case.
More info needed (Score:3, Insightful)
If you want 'easy' with a slightly 'limited' set of options long term, then I would say Windows Forms in a .NET language, use Mono rather than VisualStudio so you have a much easier chance of it working in Linux out of the box, and most likely OSX, FreeBSD and several others in the process. Its not required, but Mono's code completion will point you in the right direction where as VisualStudio is going to point you more towards MSy things. Though VisualStudio is much more enjoyable to use in my opinion. If you've never used either, its not likely to matter for a while I suspect, though on OS X, Mono seems to miss most initial clicks I send to it, could just be me.
That will give you all the basic controls an application gui will need and make it so you can reuse the massive amount of examples out there.
For your custom painted widget its a little different. What kind of painting are you doing?
Is it something that lends itself to OpenGL really well? If its fits well into geometric primatives, then I would go with OpenTK's OpenGL Control. Works pretty good in my experience.
How often does it update the displayed data? Is it a game/animation kind of thing or are we talking about something that renders once after the user changes a setting?
If you need a high FPS on the updates, you're going to want to use OpenGL with textures for displaying the rasterized data. You're learning curve will be a little steep I think if you're starting from no knowledge, but its probably your only solution for something that needs to be fast (I'm just flat out ignoring DirectX, which for Windows would be easier than OGL but would cut you off of Linux and the advantages on Windows aren't that great really)
If you have real slow update rates, then you could just throw a image control on a form and paint the pixels yourself one at a time, or load images from a file/resource.
If this is a project that has a long expected life and will become rather complex and need high performance eventually, then you're probably going to do it wrong the first time no matter WHAT you do now, at least, thats my experience. I never get it right until AT LEAST the 3rd rewrite :/
He's looking for drawing, not a toolkit! (Score:5, Insightful)
Stop suggesting various toolkits, that is NOT what he is looking for.
He is looking for a "canvas" widget, meaning he wants drawing API.
It is unfortunate that most drawing apis are tied to particular toolkits, so he may have to choose one, but if you are comparing them you have to compare the 2D drawing primitives.
There is also Cairo and OpenGL, which are not really tied to toolkits. Though you still need to jump through hoops depending on the toolkit to get it so the graphics calls draw where you want. Sigh.
Re:properly abstract your UI and it won't matter (Score:3, Insightful)
When separating your OS-dependent code, many people make a nice wrapper library for the various toolkits. This is a great way to reinvent the wheel yet again.
However, if you program is oriented around the GUI (a file manager, IRC client, etc), there is no good reason to separate GUI... you'll just end up with a poorly documented GUI abstraction layer. You'd be better off using any other portable GUI toolkit.
Re:Obvious choice is OpenGL (Score:3, Insightful)
Now draw a bezier curve.
Now draw a circular gradient.
Now draw a button with the text "OK" on it.
If all you want to do is draw some textured quads, it's not terrible. However, textured quads can only get you so far, and what the original poster really wants is unknown.
Just pick one. (Score:1, Insightful)
It really doesn't matter which one you pick. They all have strengths and weaknesses. Choose one and become an expert.
No matter which one you pick, I promise you it will be the wrong choice, and you will eventually come to understand why it is wrong, and you will pick a different one. Then you will lather, rinse, and repeat. In a decade you will come back to your original choice, and you will understand that it is your best answer because it's the one you know backwards and forwards.
Re:Easy Choice (Score:1, Insightful)
The game League of Legends uses Adobe Air for its interface, and it has been utter shite in performance and stability. Not sure to what degree that is Air's fault versus the developers, but thought I'd add this word of warning.
Re:properly abstract your UI and it won't matter (Score:3, Insightful)
Nicely abstracted UIs and awesome user experiences are two orthogonal concepts.
Re:Obvious choice is OpenGL (Score:2, Insightful)
Now draw a button with the text "OK" on it.
NSFont *font = [NSFont fontWithName:@"Helvetica" size:18.0f];
NSDictionary *fontAttributes = [NSDictionary dictionaryWithObjectsAndKeys:font, NSFontAttributeName, [NSColor whiteColor], NSForegroundColorAttributeName, [NSColor blackColor], NSBackGroundAttributeName, nil];
NSAttributedString *string = [[NSAttributedString alloc] initWithString:@"OK" attributes:fontAttributes];
NSImage *image = [[NSImage alloc] initWithSize:string.size];
[image lockFocus];
[string drawAtPoint:NSMakePoint(0.0f, 0.0f)];
NSBitmapImageRep *bitmap = [[NSBitmapImageRep alloc] initWithFocusedViewRect:NSMakeRect(0.0f, 0.0f, image.size.width, image.size.height)];
[image unlockFocus];
GLint button;
glEnable(GL_TEXTURE_RECTANGLE_ARB);
glGenTextures(1, &button);
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, button);
glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA, bitmap.size.wigth, bitmap.size.height, 0, GL_RGBA, GL_UNSIGNED_BYTE, [bitmap bitmapData]);
float rectangle[8] = {0.0, 0.0, 0.0, bitmap.size.height, .....} // Make the button what ever shape you want.
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glVertexPointer(2, GL_FLOAT, 0, rectangle);
glTexCoordPointer(2, GL_FLOAT, 0, rectangle);
glDrawArrays(GL_QUADS, 0, 4);
[font release];
[fontAttributes release];
[string release];
[image release];
[bitmap release];
Doing this all in OpenGL then makes it dead simples to animate and tranform and move around the screen.
Or you know, you could do:
QButton ok = new QButton("OK");;
Re:Easy Choice (Score:3, Insightful)
And also really, really bloated memory usage, widgets that don't act like native widgets, and the ability to make use of my laptop's nifty fan like no other. Seriously. Two hundred tabs in Firefox, and the laptop would remain quiet. Open up an AIR app and... it gets hot and the fan goes nuts. Take a look at most of the desktop Twitter clients as an example. TweetDeck is a good one because it highlights most of my issues. It runs on OS X, but not well. I was able to put up with using ~1gb RAM for a small data set, but couldn't handle with the constant stealing of keyboard focus. TweetDeck does these nifty little notifications (similar to Growl for native Cocoa applications) to tell you of significant events that happen while it is in the background. Sure, they look pretty, but they'd managed to grab the input focus roughly every other time they popped up. Sure you could type into the input boxes, but they standard OSX keyboard navigation shortcuts didn't work. IIRC the widgets didn't handle scroll wheel (or touchpad) inputs properly either. In short, the application felt like it was written by a two year old. With the exception of the notifications (which no other AIR app I've tried has dared to do), the complaints are eerily similar.
Maybe AIR attracts incompetent developers en masse. Or maybe AIR just puts the lowest in lowest common denominator. It may be a breeze to develop with, but you're putting your end users through the ringer if you go with the Adobe route.
Re:AWT or OpenGL (Score:1, Insightful)
I haven't used any of those other toolkits you mention, but compared to Tk, Swing's API is just horrible. Maybe there are some third-party layout managers that don't suck? Because all the built-in ones certainly do.
Part of the problem is Java itself, of course. For example, the lack of lambdas makes the listener pattern extremely verbose, and it looks like the lambdas that are supposedly coming in Java 8 won't actually help because they only work for single-method listeners, and most of Swing's have several methods.
Ha ha ha! That was a very funny joke, sir. I congratulate you.
Hardware acceleration of Java2D is great on Windows, where it uses DirectX. On Unix it rarely even works, and is AFAIK still disabled by default. It is completely broken on Solaris, and pretty unreliable on Linux in my experience.
And raw drawing in Java also has a poorly designed API. For example, why the hell does java.awt.Graphics.drawRectangle() not accept a java.awt.Rectangle as a parameter?
I do still agree that Java is one of the better choices for cross-platform GUI building, by virtue of not being overcomplicated and error-prone like C++ or unbearably slow like Python; but if this is the best we can do, I weep for the future of the human race.
Re:Curses AMEN! (Score:3, Insightful)
I've never seen a gui project that didn't get bogged down in the problem of the PMs and everybody down to the second owner's third wife wanting to repaint the bike shed a different color, and change the workflow at the same time, while all the time confounding the issues they create even further by not knowing the difference between the two.
If the problem is actually somewhat complicated, implement each action as a straight-to-the-shell command line interfaces, invoke them on the server side via python or perl with apache on top -- and let some poor sucker straight out of college do the gee-wiz gui dance.
This way you get your own work done, and can create a solid platform for whatever craptastic client interface they come up with -- and the data can still be maintained, the QA on the actual backend algorithms can be implemented, and at least *you* have accomplished something on time and under budget.
Let the kiddies who made the mistake of getting into GUI at all fight their own way out of it.
Re:Obvious choice is OpenGL (Score:3, Insightful)
What makes you think one cannot easily wrap that OpenGL into a single function, as well?
The advantages being it's a billion times faster, and that it just does what you actually need. The disadantage being more work, which in this context -- personal use, learning programming -- isn't even a disadvantage. Reinventing the wheel as *you* need it is a big part of learning to code, no?
Re:HTML and Javascript? (Score:3, Insightful)
That's a good point here in that Qt isn't just a GUI. It's a complete application framework, including threading, super easy mutexes, thread pool automation, multimedia, scripting, etc.
The GUI is only a small part of the Qt library.