We, the authors, felt that trying to design everything at once was too large of a task. We decided that we would choose to pursue one half of 2D Graphics I/O and that input meant and means very little unless there is some definition of what the user's input is in relation to. Just as if a user simply typed into a console without any initial prompt or resulting feedback.
 
It is, of course, possible to design an input API first, but until that API relates to some output that the user experiences, it has no tangible meaning. It is simply keystrokes, mouse or touch movements, or clicks or taps. Meaning could be assigned to them in some way by users (viz. the theremin), but the input would have no ties to anything other than a blank screen.
 
As such, we decided to focus on output first. The design of any Standardized API is a collaborative process that often undergoes numerous revisions as a result of feedback from various sources that is channeled into the committee by representatives who champion various views and opinions. It was, and remains, our belief that when there is a consensus around the output API, that consensus and all of the design decisions that went into formulating it will make it easier and faster to create an input API. By way of example, look at P0267R6 and R7 compared to R8 and R9. The design evolved radically once Guy hit upon the front end/back end template solution to resolve the issue of how much traditional standard library implementers would need to do and how much various parties who wished to provide an optimized version of 2D graphics would need to do (without needing to implement the entire STL).
 
If an input API had been designed around R6, it would've required serious modification in order to fit in the the current output API. Now look at N4073. As the primary author of this proposal, I cannot even begin to imagine how much more time would've been needed to transform an input API that was modeled after the design in N4073 as compared to its successor, P0267R0, let alone modifying it up through to R9. Indeed, text rendering was removed from the API after R2 because we determined that that alone was a complicated problem that the API in R2 did not sufficiently address.
 
So ultimately 2D graphics was split into graphics output followed by text rendering followed by input. At this stage I feel confident that the output design is fundamentally sound. That is why one of the major additions to R9 was text. Note that text is not complete. It is a starting point. That said, I believe it is a solid base that the remaining pieces can be built upon. It is my belief that once the new text API is examined and feedback is gathered and revisions are made based on that, output will be done and at that point it will be proper to spend time on an input API. That API will describe input to a substantively approved output API and as such will evolve on its own, with little to no change to the output API.
 
It would have been possible to attempt input and output at the same time. We decided to tackle output first. I believe that the revelations that caused us to withdraw the text API that was present in R2 (text being part of output) validates our decision to pursue an output API first. This is just an opinion, albeit one based upon several years of working on 2D graphics standardization. That said, feedback from the committee has resulted in many changes to the API, most recently from the San Diego 2018 meeting, which led to the creation of the command lists feature. (No review of P0267 took place an Kona 2019).
 
I added many of the primary features of a text rendering API to R9 along with command lists because I believe that the addition of command lists essentially completes 2D graphics output (excluding text). Excluding proper text rendering, there is one more addition to be made, a Bezier surface brush, which is required to meet the ISO 32000-1 standard (the PDF 1.7 format).
 
All of that said, I do have one item of reference material at hand that supports our decision. The organization of Computer Graphics - Principles and Practice, 2d ed., Foley, van Dam, et al., Copyright 1996 Addison-Wesley Publishing Company, Inc., Reading, MA. (Apologies if my citation format is incorrect). In it, Foley, van Dam, and the other co-authors address 2D graphics output first and only after that is finished (along with a brief foray into 3D graphics), i.e. the first seven chapters, do they begin to address input (chapter 8...).
 
But it really was just a choice, one made long before any of us happened to have a copy of Foley and van Dam in reaching distance. I hope that I respectfully stated the reasons we chose output first. If my response does not seem respectful I sincerely apologize and ask that you forgive me. I've been awake for well over a day just now (the mailing deadline was almost 12 hours ago and adrenaline has been flowing through me ever since!).
 
Best regards,
 
-Mike
 



On Mon, Jun 17, 2019 at 7:07 PM Rene Rivera <grafikrobot@gmail.com> wrote:
On Mon, Jun 17, 2019 at 12:42 PM Michael McLaughlin via SG13 <sg13@lists.isocpp.org> wrote:
The next revision of 2D graphics will be presented at the upcoming Cologne meeting. As opposed to making everyone wait for the mailing, if you would like, you can access R9, the paper submitted for the pre-meeting mailing, here: https://github.com/cpp-io2d/io2dts/blob/master/papers/P0267R9.pdf .

Even though I'm still reading the paper I feel I should point out something that struct me in the "Introduction", while reading this statement:

  "...the design of an input API is inherently reliant on the design of the output API..."

and how it's used as a justification "to only pursue of the input API after the output API design was complete." In my experience I don't see any truth in that statement no matter how hard I try to think about it. Maybe my experience in the user interaction field is limited, but I can't remember a case where a rendering, i.e. output, API was required for the input. Can you provide some reference material to support your claim in this respect?

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net