Lightweight Drawing Library

Objectives, Requirements, Strategies

This paper suggests objectives, requirements, and strategies for SG13, the C++ committee's graphics study group. These ideas were presented to SG13 at their organizational meeting in Chicago on September 28th. They are my personal views and do not necessarily represent the views of other SG13 members. The general ideas presented here were developed over a number years watching endless discussions on the Boost developers list that never reached consensus, let alone produce a tangible library proposal.

Objective: Success

This paper isn't about the technical aspects of a library technical specification (TS) for a lightweight drawing library - rather it presents an approach to creating such a TS in a way that maximizes the chance of success.

Elephants in the room and differing expectations

There are already heavyweights in the general problem domain - Microsoft, Apple, Open GL, QT, and many others. SG3 needs to ensure that these interests understand that we are not trying to move in on their turf.

A related problem is that past discussions have shown that it is hard to get agreement on technical issues because expectations differ widely with regard to scope for broad topics like "graphics interface".

One strategy to defuse these concerns is to choose a title for both the SG and the TS that zeros in on the small portion of the larger domain under consideration, and then add an adjective to indicate small and simple rather than big and complex.

A more limited name like "drawing library" best reflects the intended scope of the SG.

Including an adjective like "Lightweight" or some synonym further reins in expectations and allows more rapid progress. The "Concepts Lite" SG is an excellent example of this.

Suggested names: "Lightweight Drawing Study Group" and "Lightweight Drawing Library Technical Specification".

Avoiding design by committee

A lightweight drawing library, even though far simpler that a full-fledged graphic framework, is much too complex to be successfully designed by a committee. Two strategies are presented that taken together addresses this concern.

Strategy: Ship in two years

That implies a major feature complete working draft (WD) in one or two meetings. I.E. There is no time for design by committee.

Strategy: Start from an existing successful library already in wide use

Starting with an existing successful library that is already in wide use avoids design by committee and gives the SG and standards committee confidence to move forward quickly. It will also help to have working implementation (on GitHub or similar) that is kept in sync with the working draft and can be experimented with both by participants and ordinary users. That, coupled with starting from an existing library, will build confidence that the WD is implementable and useful to users.

The strategy for accepting the STL into the standard is a useful role model. The whole STL proposal was put in the standard working draft, and only then were changes allowed. This had the effect of moving the STL forward quickly and limiting design by committee related problems.

Once SG13 has a working draft, we can accept changes of any magnitude based on the merits of their proposals. If someone comes forward with a proposal to completely replace the library as specified in the WD, that proposal obviously would have to be very strong to make progress. Smaller proposals, particularly those that have been implemented (presumably as a branch of the GitHub implementation), might well be accepted, and smaller tweaking proposals will certainly be accepted. But at each step of the way, the SG has a complete WD and reference implementation.

Requirements for a starting point library

• Existing successful library already in wide use.
   

• Modern C++, modulo naming conventions and C++11/14 features. (Dependencies hidden from users are exempt from this requirement.)
   

• Extendible by third-parties. An initial library TS completed in a short time frame will likely be quite limited. That will be much more acceptable if the library is extendible by third parties.
   

• Copyright or other intellectual property holders willing to meet ISO intellectual property requirements. It will also be helpful if the original developers get involved in SG work.
   

• Meets Beman's challenge: "Display Hello C++ World in a window and allow the user to drag that text around inside the window with a program that is only slightly more complex that the traditional hello world program."
   

• Meets Herb's challenge: "Learn the library basics and build an interesting app in four hours or less."
   

• Other challenges or requirements may evolve, as long as they don't eliminate all candidates.

Does any existing library meet these requirements?

Cinder (libcinder.org/) seems to come reasonably close, although there has been no in-depth analysis yet. There are other existing lightweight libraries that SG13 can investigate.

Here are two videos showing the Cinder results for Herb's challenge at the Going Native 2013 conference:

• channel9.msdn.com/Events/GoingNative/2013/Herb-s-UI-Challenge

• channel9/msdn.com/Events/GoingNative/2013/My-Favorite-Cpp-10-Liner#time=0h8m22s

Acknowledgements

This paper is the result of numerous conversations and emails with Herb Sutter. "Drawing" is chosen for the titles at his suggestion.