Graphics Libraries

[hassanAman]

Hello everyone, I just wanted to ask, is there a C++ original graphics library? Like java has one call "Graphics2D". Is there a C++ graphics library? Or do you have to manually download one, like SDL2 or OpenGL, DirectX, etc.

[Thomas1965]

Currently a graphics library isn't part of the standard. So you have to use an external library.

[E0p9LyTq]

Is there a C++ graphics library?

There are graphics libraries that work with C++, they are not part of the ISO standard.

cppreference has a listing of known open source C++ libraries, scroll down to the graphics/multimedia library sections:
http://en.cppreference.com/w/cpp/links/libs

[Repeater]

For those who like to follow this sort of thing, the graphics proposal lumbers onwards. Here are a couple of recent posts about it:

https://hatcat.com/?p=16
https://hackernoon.com/a-cake-for-your-cherry-what-should-go-in-the-c-standard-library-804fcecccef8
https://abseil.io/blog/20180227-what-should-go-stdlib

and an older one:

https://www.quora.com/Why-doesnt-standard-C++-have-graphics-libraries


Personally, I think encasing a graphics library permanently in the standard library would not be helpful. It's so dependent on hardware and OS and so on that it seems like exactly the sort of thing that is best done in third-party libraries.

[Thomas1965]

Why should the hardware dependency be a problem?
The standard need only to specify a kind of interface and each compiler vendor could create it's own implementation.
It would make teaching C++ much easier for beginners - no third party libraries to compile or install.

[Repeater]

It would make teaching C++ much easier for beginners

I hear that one a lot. I think that's a very bad reason to put something in the standard library. The standard library does not exist to make teaching things easier.

Why should the hardware dependency be a problem?

Lots of hardware doesn't have the capability to show graphics at all, so that's all out of the picture right from the start.

On OS and hardware stacks that can support it, you've now got the GCC (and others) standard library team having to endlessly write libraries to intereact with an endlessly changing, always updating operating system API and associated hardware. No guarantee of anything apart from the operating system API. Seems like it shouldn't be the job of the GCC maintainers to be constantly updating to match this endless array of OS APIs, but if it's in the standard, that's where we are. So we're writing a slow graphics library with minimal functionality. Can't rely on the existence of accelerated graphics hardware and drivers, so the performance will be awful. Anyone who really wants to make use of graphics will use something that actually works well with their hardware. Who exactly is this crappy, quickly fossilised graphics library for again? Oh, to make it easier for people to learn how to draw lines in C++, except that once they actually learn they'll leave the C++ standard graphics library behind fast because they get much more functionality, probably much more easily, using something made for their OS and hardware.

So yeah, it's not a problem; it just ties us to a crappy library with poor functionality, trying to meet some minimal set of functionality on all possible OSes on all possible hardwares, for no serious benefit.

Are we going to add everything to the std library so that newcomers don't have to learn what a thrid party library is? If that's the whole argument - it's to help people do things without needing a third party library - then that argument never ends, until eventually all possible libraries are in C++.

We already have simple graphics libraries that do what's needed. For the cost of a newcomer actually taking a few hours to learn what a library is and how to use it, they can have it already. The C++ library should not be a substitution for incompetent teachers.


I'm sure there are various nit-picks to be made above, but basically, my argument is that the C++ std library does not exist to cover incompetent teachers, and that a graphics library that tried to cover all possible implementations on all possible OSes on all possible hardware is going to be too bad to use seriously, and something that nobody will use seriously shouldn't go into the std library.

[JLBorges]

> It would make teaching C++ much easier for beginners - no third party libraries to compile or install.

Why would a graphics library be an essential requirement for teaching C++ to beginners?

Why shouldn't building/installing third party libraries be a part of learning intermediate C++?

There is a proposal for the addition of a 2D graphics library (based on Cairo)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0267r7.pdf

(I hope it doesn't make it.)

[Cubbi]

JLBorges wrote:

Why would a graphics library be an essential requirement for teaching C++ to beginners?

Because the computers they have in their pockets do not have a console window.

To be fair, the 2D graphics library proposal does not include text rendering of any kind yet (section [io2d.text] is empty), and so won't achieve that goal (the goal of printing "Hello World" on a modern computing device).
But it does make it possible to write a little asteroids game: https://github.com/mikebmcl/P0267_RefImpl/tree/master/P0267_RefImpl/RocksInSpace

[keskiverto]

Because the computers they have in their pockets do not have a console window.

True. You can either include a terminal to the default pocket install, or add stuff to the C++ standard. The first is trivial.

But why add graphics then? Pockets are so small. Why not focus on audio? Surely we can talk to our pockets and Siri/Alexa can respond "as easy as" staring pixels is?

[Cubbi]

Repeater wrote:

Anyone who really wants to make use of graphics will use something that actually works well with their hardware

btw, this is not new. Anyone who really wants to make use of a console window today uses something that actually works with their OS and terminal rather than stdout/std::cout: you can't write vi or even nano in standard C++.

keskiverto wrote:

But why add graphics then? Pockets are so small. Why not focus on audio? Surely we can talk to our pockets and Siri/Alexa can respond "as easy as" staring pixels is?

You're trying to be sarcastic, but standardized access to audio/video codecs would make a very welcome SG14 proposal. Although it would probably die like the standardized access to databases did, due to lack of a de-facto standard.

[JLBorges]

> Because the computers they have in their pockets do not have a console window.

The implementation of the (current) standard library for such a device could (should) provide support for the standard stream objects. (Implementing stdout would be trivial; though stdin may be trickier.)

[Thomas1965]

Who exactly is this crappy, quickly fossilised graphics library for again?

Why should it be crappy?
In the old days Turbo C came with a simple to use graphics library that was very easy to use and good enough for some simple games.

Why would a graphics library be an essential requirement for teaching C++ to beginners?

It would learning more fun - especially for kids.
How much fun is it to write only console apps?

[Repeater]

Why should it be crappy?

Because it's the lowest common denominator. It has to work everywhere.

It would learning more fun - especially for kids.

I get that for you, making learning C++ fun for children is a high priority. My priorities for C++ differ. On this one, we simply disagree.

[jonnin]

I don't think it would have to be "crappy". Ok, the LCD thing has merits, but there are c++ codes that are not supported on all the micro platforms, eg arduino has some weirdness on what you can and cannot do. So like that, it could be supported on most platforms and if you are coding on that wristwatch that someone stuck linux on, or your linux os router, etc ... maybe lacking a display device would mean you could not use the thing. Ok. Then you have the rest of the machines in the world and something like a c++ opengl platform embedded in the language would be sort of nice. Lets say you did that...

-it would need to be maintained; graphics grows at an alarming rate as the hardware and industry push the limits!

Because of that alone, its not feasible. The constant updates and growth and changes to keep pace with driver changes and efforts to maintain a cuda usage case etc would burn up all the c++ growth efforts, there wouldnt be anything left for growing the language. As it stands today, you can simply link in a library and be using graphics that suit your needs (gui/2d/3d/ whatever) on any platform with relative ease and minimal effort. The experts maintain the graphics stuff, and c++ grows in ways that make the language better without becoming bloated and bogged down trying to reinvent the wheel. (granted, all language growth efforts are reinventing the wheel, but this is a rather wheel).

[Repeater]

As it stands today, you can simply link in a library and be using graphics that suit your needs (gui/2d/3d/ whatever) on any platform with relative ease and minimal effort.

Exactly. The only people who benefit from C++ having std::graphics are people who can't do that. I sympathise with them - we were all beginners once bashing away at linking libraries - but the cost of showing them how is much lower than the cost of adding std::graphics.