A Proposal to Add 2D Graphics Rendering and Display to C++ [pdf]
isocpp.org
isocpp.org
Now that this principle seems to be abandoned why not go all the way and give us a full GUI toolkit? That would be so much more versatile than just a 2D drawing API.
I do not see much use for this except maybe making ISO C++ tutorials more exciting because your programs can show something else than console output.
And I mean Cairo is not a simple framebuffer, it is quite complex so why not make another step and give us a full GUI?
I read that the C++ guys want a standard library comparable to those of modern languages like Java, C#, Python etc. and they all come with GUI support.
Oh, and before they even think about adding graphics they should beef up the file system API. That is an actual issue. Right now every piece of crossplatform C/C++ includes a wrapper around platform specific APIs just to handle something as basic as getting a list of all files in a directory. They want to give us vector graphics rendering before that?
It's being worked on. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333... and I think that it should be part of C++14 or C++17 http://isocpp.org/std/status.
http://isocpp.org/std/the-committee
- SG1, Concurrency
- SG2, Modules
- SG3, File System
- SG4, Networking
- SG5, Transactional Memory
- SG6, Numerics
- SG7, Reflection
- SG8, Concepts
- SG9, Ranges
- SG10, Feature Test
- SG11, Databases
- SG12, Undefined and Unspecified Behavior
- SG13, Graphics
Any modern language should have a "batteries included" set of libraries, even when targeted for systems programming.
I would argue the inverse: modern languages should have a lean standard library but a strong package ecosystem.
Can you provide the same guarantee with a package system?
I don't what to target operating system XYZ only to find out the package does not exist.
AGG - http://antigrain.com
http://beta.slashdot.org/submission/3154635/rip-maxim-sheman...
AGG is amazing and I always thought Maxim was a little bit of a genius.
It's a bit embarrassing when someone used to the standard library from most other languages asks "How do I draw this picture of a cat" or "how do I print 'Hello World!' in red in a welcoming font" and you have to say, erm, well.. there is nothing in c++ for that. Maybe you can find a platform dependent library that will work for you.
It doesn't need a library to do everything, but something that lets you draw and write text to a window seems like something that should be available on every platform that can support it.
The rest of the document reads like someone just discovered the Cairo library and wouldn't it be cool if we jammed this into our already overly-bloated standards document?
There is no all-purpose graphics library. What's good for games isn't necessarily good for rendering PDFs and vice versa.
Also, the purpose is pretty obvious if you look at the use cases of Cairo and it's obviously not meant for (serious) game making, but there already is an open standard for that.
> How many cross-platform 2D graphics libraries are there?
The document itself points out 4 cross-platform libraries. A simple Google search for "cross-platform 2d library" yields at least a dozen more.
> Also, the purpose is pretty obvious if you look at the use cases of Cairo and it's obviously not meant for (serious) game making ...
They explicitly state that they want to serve rendering of any type, including games.
No, the comic describes a situation with 15 competing standards. This is the first standard of it's kind.
>> The document itself points out 4 cross-platform libraries.
The document points out Qt, Cairo, GTK+, or SDL. Let's not count Cairo since this is basically Cairo. Qt is not GPU accelerated (nor is it a graphics library, Qt's graphics library is called Albert I believe) and GTK+ is not really a graphics library either and AFAIK, it itself relies on Cairo. So the only contender is maybe SDL (idk I don't know much about it, but it appears to be higher in the stack). And yeah, Google search does yield a lot of results. Similarly, if you Google for 'programming language', you will also get a lot of results. That does not mean that all of them are interchangeable or that all of them can be used for general purpose computing. If you are going to build a serious project, you will probably choose a platform with some support (such as a standard implemented by several vendors) behind it.
The only real contender that comes to mind is Skia (of the Chrome and Android fames).
>> They explicitly state that they want to serve rendering of any type, including games.
They're talking about 2D games.
I think C++ gets the most flack for being too complex and bloated. But when you compare it to Java and C#, C++11, the language (based on language specification word/page count), is smaller than Java and only a little bigger than C#. The C++11 standard library is much smaller than both the Java 7 SE and the .Net (FX only) libraries.
Source: http://media.ch9.ms/ch9/5c51/d30749f7-09d7-4266-bd57-d1d4461..., just after 15 minutes in. Or http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%..., slide 14 and 15 (see the top-right corner of slide 14 for the metrics used for the comparison (page/word count of the language specs). EDIT, for context: the speaker/author referenced is Herb Sutter, member of the C++ standisation committee, and one of the authors of the graphics proposal in question.
By contrast, C++ requires that the user understand most of the minutiae, details, corner cases, and weird things that the language describes just to get a rather low level of competence.
The length of a language spec has little to do with its usability.
I watched the presentation where Herb Sutter said that, and I think that claim is disingenuous, because the Java Language Specification is much wordier than the C++ spec.
For example, the section on integer literals in the JLS is 1.5 times longer (measured by word count) than the same section in the latest C++ draft. Is it because Java's literals are more complex than C++? No, it's because of things like explicitly listing the minumum and maximum numeric values of int and long literals (in each of decimal, hex, octal and binary)
In general, I think that the terseness of the C++ spec is not a good measure of the relative simplicity of C++.
But I concede the point of complexity; the C++ spec is no doubt more dense. I just don't think it deserves to always be singled out as the most overly-complex/bloated language. The difference is not as big as the cliche would have people believe.
Also, the article is about adding to the standard library, which is much smaller than Java's and .Net's, so invoking bloat is probably not appropriate in the context of the article.
Graphics has very limited usage without full GUI. I can think of only games and chart-rendering applications (or similar) that don't really need GUI. But games require some means for windows-handling (like GLUT in OpenGL). And "chart-rendering" require output routines to produce PDF/PS/SVG/PNG.. In any case, you need quite a lot of auxiliary IO functions to really do anything useful. So, how much of thes auxiliary stuff will be included in the standard library?
Also, if they plan to implement output with both DirectX and OpenGL, there is quite a lot of work to ensure that everything works on computers with GPU, without GPU, with ancient GPU, on Windows, Linux, OSX and actually looks roughly the same. This is not easy, if you want to do it efficiently.
For game development, beginners choose Flash game engines, or GameMaker, or something like that. I doubt that C++ can work better for them, even with Cairo built in.
The standard library will always have limitations, so you will need to use external libraries at some point anyway. And a transition to an external library can be difficult, if the standard library is already used extensively.
Yes, probably, humongous standard library is good for cross-platform development, but it must be implemented first. And again, external libraries are sometimes necessary anyway. Also some UI libraries are already cross-platform, like Qt, btw.
The standards committee is conserned about portability, at least on a technical level. I wonder what their take is on portability issues caused by license terms.
This might lead to C++ library vendors not implementing the standard and requiring using a third party library, perhaps later integrating them into their own libraries.
Thinking about it, it is not probably a bad thing, it will just take longer than with other parts of the standard. Of course, this is just pure speculation and things might turn out very differently.
Why not just knock off a good API, like that for <canvas>?
1. It includes some extraneous things such as some CSS stuff. 2. There is some evidence that some of the canvas api may be covered by patents.
I think Cairo just borrowed the PostScript drawing model from the start.
Adding every conceivable library as standard doesn't make sense, unless you're Java, in which case no one cares how much crap you bring along.
"Batteries included" works very well in many cases. Having a single de-facto dominant implementation helps.
Every language should have a proper set of "batteries included" in the standard library.
One is not forced to use every single feature on every program.
Extra batteries imply a greater codebase that has to be maintained, must support all modern architectures and compilers, and must evolve in a graceful way while maintaining backwards compatibility.
In general, backwards compatibility is a pain in the neck and results in libraries not evolving once they reach the standard library.
Python has tons of examples: urllib, urllib2 (both of them superceded by Requests, an external library that manages to incorporate a sane API), multiple subprocessing libraries, several refactorings of the OS exception hierarchy, etc.
Oh, and nobody actually uses the included GUI library for anything except the smallest of trivial examples.
This is something that can be tolerable in some high-level languages where performance is not a concern, but systems programming languages should tend to more conservative defaults and things that can be used in production to a certain degree of satisfaction.
Nobody is going to be happy with the default GUI lib in at least one of the many platforms; the existence of dozens of UI toolkits with different idioms, different looks, and different levels of integration are proof of that. And contrary to some more basic use cases, UI libraries tend to be, by necessity, absolutely enormous.
If the end result is going to be another poorly-designed library like many of the STLs modules, I'd much rather developers use the proper UI toolkit for the situation.
C++ is usually compiled to native code.
A portable package system needs to provide support for all compilers and operating systems targeted by C++ compilers.
I want to be able to write code that does not depend on the convenience from some hobby developers to support AS/400 systems, for example.
Libraries in C and C++ are a pain to use, because they are only available for specific operating systems, specific compiler versions and tend to lack compatibility among themselves.
This pain also tends to be part of C culture, as other system programming languages already had the tradition to provide a proper set of libraries on their runtimes.
I think the main cause is that UNIX is actually C's set of libraries, but those libraries do not exist in all operating systems.
However having a set of libraries as default, is great for the guarantee to be able to write OS agnostic code.
No one is forced to use them, if they required more advanced use cases.
There's half a dozen blitting models with difference performance optimizations. You have at least 4 or 5 popular widget toolkits. Do you support 2D drawing? 3D?
There are some things that just can't be abstracted away without massive engineering costs. No portable standard UI toolkit would be complete and compatible enough to be used for serious applications unless they're willing to stoop to levels as low as Java's so-called "multiplatform" UIs, which honestly look like crap.
A UI toolkit that's low-level enough is useless in desktop and modern mobile platforms. At higher levels they're too OS and device-specific. If they're too device-specific they have no place in a standard library. Thus, no UI toolkit is apt for this space unless you're willing to settle for mediocre, second-class toolkits.
Begineers and people that care about presenting simple stuff will do surely use it.
The idea is to have good enough libraries to write portable code for simple stuff.
Should anyone have to go though the pain of creating a OpenGL context, matrixes and shaders to put some text on the screen?
You are always free to go write Win32, Xlib, Qt, GTKmm, MFC, Motif, wxWidgets, WPF, embedded Chrome or whatever UI flavor of the months is for REAL applications.
It is indeed helpful in other areas, though.