
A Proposal to Add 2D Graphics Rendering  and Display to C++ [pdf] - adamnemecek
http://isocpp.org/files/papers/N3888.pdf
======
copx
In the past the argument against putting things like this in the standard
library was always that it is non-portable. C and C++ are meant to run on
systems which do not even have a monitor, much less a GPU (think embedded).
The logic was that standard library functions should work on all systems. That
is also the reason why the "file system" API of ISO C/C++ is so severely
limited. It is designed for the lowest common denominator. There are no
functions for handling directories because of the assumption that some
platforms do not even have directories. In fact the file system API does not
even assume a hard disk but can be implemented by returning handles to RAM.

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?

~~~
pjmlp
If you check the working groups there are lots of APIs being worked on,
including file system ones.

[http://isocpp.org/std/the-committee](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.

~~~
the_mitsuhiko
> 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.

~~~
pjmlp
A standard library is a guarantee that all packages are supported in the
target environments for the language.

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.

------
rwbt
I'm not sure about Cairo, but IMHO AGG is probably one of the best C++
libraries out there. Great use of C++ capabilities like templates. Too bad,
development isn't active anymore.

AGG - [http://antigrain.com](http://antigrain.com)

~~~
adamnemecek
Oh shit, apparently the guy behind AGG, Maxim Shemanarev, died 2 months ago.

[http://beta.slashdot.org/submission/3154635/rip-maxim-
sheman...](http://beta.slashdot.org/submission/3154635/rip-maxim-shemanarev)

~~~
sigmaml
I came across AGG very recently. Yes, several parts of the code are designed
and implemented very well. Unfortunate that Maxim died.

------
jbb555
C++ needs _something_.

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.

~~~
ahomescu1
"Most other languages" seems like an exaggeration. I don't think you can do
any of the things you list easily in Python, PHP (you wouldn't even want to in
PHP), JavaScript or Haskell.

~~~
hendzen
Python includes Tkinter for GUI programming. That said, Tkinter is pretty
crappy compared to PyQt.

~~~
Daishiman
The number of users of Tkinter in Python is so low that I would seriously
question its utility in the standard library. IDLE is the only piece of
software that I know of that targets it, and it's quite underwhelming.

------
rcfox
The motivation reads exactly like the xkcd comic on standards.
[http://xkcd.com/927/](http://xkcd.com/927/)

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.

~~~
frankzinger
_...wouldn 't it be cool if we jammed this into our already overly-bloated
standards document?"_

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...](http://media.ch9.ms/ch9/5c51/d30749f7-09d7-4266-bd57-d1d446165c51/GN13HerbOneCpp_mid.mp4),
just after 15 minutes in. Or
[http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%...](http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fvideo.ch9.ms%2fsessions%2fgonat%2f2013%2fGN13_Sutter.pptx),
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.

~~~
edmccard
>But when you compare it to Java and C#, C++11, the language (based on
language specification word/page count), is smaller than Java

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++.

~~~
frankzinger
Well I think the idea is that it is a good general metric which should average
out over thousands of pages. Just because one section of the Java language
spec is wordier than the corresponding one in the C++ language spec does not
mean it holds for the entire document.

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.

------
JasuM
Cairo is dual-licensed under the LGPL and MPL. Both of these are restrictive
enough to make them incompatible with, eg., App Store terms. Yet the proposal
does not seem to even mention the license (or maybe I just missed it).

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.

~~~
pmelendez
They wouldn't be using the library code. They would just specify what have to
be implemented based on the library. They have been doing this with all the
libraries that they include in the standard (such as part of boost) and most
of the time the resulted specification is way simpler and limited than the
original inspiration. Also this is a design for implementation, once done each
implementer have to decide how to make it real.

~~~
JasuM
Boost has a very liberal license, unlike Cairo. C++ libraries, at least the
GNU C++ library, have directly based some of their implementations on Boost.

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.

~~~
pmelendez
You have a point if implementers choose to use cairo code instead of re-
implementer it, but in the other case they don't need to follow any license at
all since licenses are valid just for code, unless they have patents on it
(which I don't think is the case in libcairo)

------
angersock
It's not quite the Java 2D API, but damned it's close.

Why not just knock off a good API, like that for <canvas>?

~~~
fyolnish
Cairo & <canvas>'s drawing models are rather similar iirc.

~~~
thristian
The <canvas> drawing model is a very thin layer over the Mac OS X Cocoa
drawing model (because it was originally developed by Apple as a proprietary
extension to Webkit). The Cocoa drawing model is based on the "Display PDF"
model, which is a descendant of the "Display Postscript" system used by the
original NeXT OS, which of course was derived from the PostScript page layout
language.

I think Cairo just borrowed the PostScript drawing model from the start.

------
midas007
Third-party libraries are third-party for a reason.

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.

~~~
zurn
Other platforms doing this include Python, Erlang, Perl, and C#.

"Batteries included" works very well in many cases. Having a single de-facto
dominant implementation helps.

~~~
Daishiman
None of those languages are meant for systems programming.

~~~
pjmlp
So what?!

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.

~~~
Daishiman
You're making the situation far simpler than it is.

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.

~~~
pjmlp
The goal is to have something that any programmer can use regardless of the
the operating system.

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.

~~~
Daishiman
Like I said before, _nobody_ is going to use an OS-agnostic UI library because
UIs imply necessary integration and a level of specificity that can't be
generalized.

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.

~~~
pjmlp
> Like I said before, nobody is going to use an OS-agnostic UI library because
> UIs imply necessary integration and a level of specificity that can't be
> generalized.

 __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.

------
pmelendez
I know it is irrelevant but still is interesting that one of the authors is
Herb Sutter from Microsoft and that he chooses to propose an open source
library from C instead of something coming from Microsoft.

------
Someone
Earlier discussion:
[https://news.ycombinator.com/item?id=7012329](https://news.ycombinator.com/item?id=7012329)

