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_at_[hidden]> wrote:

> On Mon, Jun 17, 2019 at 12:42 PM Michael McLaughlin via SG13 <
> sg13_at_[hidden]> 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
>
>