The 2D Graphics TS

The story so far

The ISO C++ committee (WG21) did not reach consensus to pursue a 2D Graphics Technical Specification (TS) during the Rapperswil session. At the end of the week the British Standards Institute (BSI) C++ panel met for its pre-plenary caucus. This is where the panel decides what position to adopt so that the delegation lead can vote in the plenary meeting on proposals that aren’t unanimously supported, as happened with the coroutines proposal.

During the caucus, disappointment was expressed about the end of the graphics effort: the BSI C++ panel was very keen for adoption of some form of drawing library into the International Standard (IS). A long serving member pointed out that we could in fact publish our own TS, and we decided to discuss this at our next meeting, which took place on July 9th.

Wait, what?

The ISO is a federation of national bodies, of which the BSI is one. Over a dozen national bodies participate in the C++ standardisation effort. Any body can publish a TS. Indeed, the BSI has published many TSes in other standardisation efforts, but never in the C++ subject.

A C++ TS is not part of the C++ IS. Particularly, from British Standard zero:

BS 0:2016, section 3.45

A TS is a document published by ISO, IEC, CEN or CENELEC about which there is the possibility of future approval as a standard, but for which at present there are reasons precluding immediate publication as a standard.

NOTE Typically the reasons for this would be that the required support for such approval cannot be obtained; there is doubt on whether consensus has been achieved or the subject matter is still under technical development.

This TS would be developed, reviewed and published independently of WG21. There is expertise within the BSI C++ panel competent to complete this work: there are experienced wording reviewers and implementers.

The BSI C++ panel post-Rapperswil meeting

Among other matters, we discussed the idea of publishing and unanimously resolved to propose a new work item for the publication of a 2D Graphics TS based on P0267.

This is new territory for the panel, and possibly for WG21. We still have to work out the process and cannot yet publish a timetable. However, what we will deliver will be wording sufficient for implementers, if they so choose, to implement the 2D Graphics library specified by the TS.

There is already a reference implementation and sample code for Windows, Linux, OS X and iOS. Emscripten support is in development. You can take a look, download and build it by visiting We expect to add it to the vcpkg package manager very soon which will simplify access. You can also take a look at the current version of the TS: be warned, it is nearly 200 pages long.


Why do this if WG21 is not interested?

The work to date is very valuable. It contains the result of extensive feedback from the WG21 committee and can act as a beacon to others.

Consensus is a fluid thing, as is the makeup of the committee: there was very strong consensus for several years to pursue 2D graphics and it would be foolish to believe the current consensus will remain forever. Even if another approach is pursued, the TS will offer a starting point.

There is still demand for a standard drawing library. Many of the national bodies were as dismayed as the BSI C++ panel by the new consensus. By publishing a TS this library remains a visible candidate.

Why not try standardising another library?

The proposal is the result of many thousands of hours of work from a small number of wording experts and graphics experts. Starting again from scratch on something else would delay the introduction of 2D graphics by years. However, if you would like to undertake such a thing, I’m happy to answer questions.

It is often overlooked that having a great idea is only the very start of the standardisation process. Developing the API is a small part of the job when compared against generating the unambiguous wording for the IS document.

Won’t this fork the language?

This is not a language feature. The library is currently defined in the std::experimental namespace and will be migrated to the bsi namespace.

Won’t package management solve this?

Sadly, no. Adding the implementation to vcpkg gets this library into the hands of all those who are permitted to use third party code. However, this is by no means a universal privilege. Many commercial, industrial, governmental, financial, medical and military code shops simply outlaw third-party code, even Boost, allowing only what is provided by the compiler vendor.

The phrase “dark matter developer” refers to those developers who simply don’t engage with the rest of the community: they are invisible, observed only by the effect they have on compiler sales. Often, these are developers who are denied access to the work of the community. In my opinion it would be worth trying to find out how big this non-community membership is. Last year’s C++ survey was self-selecting from community participants: maybe it is time to commission some professional research. We ignore these developers at our peril. If we do not serve them they may migrate to other languages.

Should WG21 decide to standardise package management in such a way as to overcome this barrier, perhaps with a “blessed” repository, then the TS will be in a strong position to seed such a library.

How can I help?

We welcome any and all assistance. You can:

  1. Write some samples or tutorials
  2. Propose text or input APIs
  3. Develop a new implementation

Samples and tutorials are the easiest way to help. That’s how everyone learns to use a new feature.

We are thinking about text and input a lot of the time. It’s hard. One of the team is a long-term contributor to SDL and has some ideas, but it’s good to have more to choose from.

The current implementations are software reference implementations, using Cairo or CoreGraphics. Perhaps you could write a DirectX, Vulkan, OpenGL, Metal or nv_path_rendering implementation. They don’t need to be perfectly optimised: they only need to demonstrate feasibility. If you run into trouble, you might be highlighting a fault in the design.

You can also contact your national body and your favourite compiler vendor and ask them to support the effort. Remember, you’re the customer. Look for details of these organisations on the ISO C++ web site.

Post script

This is a post about governance more than about C++. If there are any errors or if anything is unclear, please add a comment below and I will correct or clarify as soon as possible.

I recorded a podcast with the good folk of CppCast about this and other topics. You can find it here. Many thanks to Rob and Jason for the opportunity.

5 thoughts on “The 2D Graphics TS”

  1. Hi Guy,

    thank you, for your incredible work and endurance for the common good of our c++ comunity!

    Here some thougts about your strategie, to advance with a TS of the BSI for the 2D Graphics library.

    Let’s consider, it will be done, say in two years from now, the questions remain:
    How many Programmers are NOT allowed to use your reference implementation, (e.g. because your internal dependencies)?
    How many Programmers are not allowed to use a foreign library?

    In contrast, I think an other Question could guide you better:
    How fast as possible can you bring your 2D Graphics library to as many programmers as possible?

    Integrating 2D Graphics into boost would bring it in really short term to the fingertips of the majority of the c++ comunity. (Without the need of a further dependency to vcpck.)
    In contrast to a standard, a boost library is a concrete thing.
    We saw books about new boost features in relative short term after there inclusion.
    So my bet would be, if you bring it to boost, the education about “how do 2D Graphics” follows your way and carve the path to more users.

    If you have furthermore energy and ambition, it would be great do get 2D Graphics under a BSI-TS, but consider: in this process you have a lot of relations to manage and many unforeseeable dependencies, not in your direct influence, and it is no direct path to us users (programmers).

    Via boost, you have the most control to bring youre invaluable work to a huge part of our community in a relative short timespan!
    So I recommend to go for this self-amplifying process via boost as the
    promising mainway.

    Thank you for the time reading this, best wishes for your effort!

    1. I agree with Andreas, a two pronged approach. First get your reference implementation into Boost, get people using it. From that you will find out any issues with the design and can make rapid changes without the overhead of adjusting a standard.

      Secondly once you have that momentum (buyin) from the community and the design has proven itself and is stable push it into a BSI-TS. The ISO are likely to then pick it up and make that the ISO standard – since not much additional work is required on their end, and via Boost you have made it the de-facto standard already.

      I would imagine that there would be enough non restricted users using Boost that the first step would be successful. The restricted users can wait for step 2 once it is proven and stable.

      Good Luck – and well done putting in the effort on this, braver man than I.

      Cheers, Ed.

      1. Thanks Andreas and Ed.

        We’re looking at Boost submission. None of us have particular experience of such a thing, but if either of you do, we would welcome any and all assistance. Go to the repo and introduce yourselves: we’re keen to get this into as many hands as possible!


  2. The world doesn’t need another graphics standard. We already use OpenGL.

    Ok ok ok.

    Apple is deprecating OpenGL. They are replacing it with their interpretation of the Vulkan open source standard managed by Khronos. Vulkan more or less includes opengl.

    Moving to Vulkan is no big deal since we are all familiar with OpenGL.

  3. Very much new to this proposal but have been working with C++ since Borland released their C++ compiler. I support the idea of a standard library. The suggestion I have is to partition the library into two sections. One to allow for console / terminal operation, i.e. NCUSES equivalent, and the other to add graphics terminal operation. It is likely that a number of applications, especially embedded system, would find a terminal system acceptable if a standard existed for its use. There would also be a number of usages for testing systems of all types.

Leave a Reply

Your email address will not be published. Required fields are marked *