We, the authors, felt that trying to design everything at once was too large of a task.
Perfectly reasonable position.
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.
Sure, although I wouldn't diminish the individual importance of input as much as you seem to be implying.
All I think I can do is respectfully disagree. Input is very important, but only if it has some meaning. And it only has a meaning if it relates in some way to output. Those are my thoughts.
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.
Right. But..
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.
You seem to be asserting that a screen is the only "meaningful" output with regards to feedback of input. The multitude of force feedback devices, light "bulb" indicators, heat surfaces, audio generators, scented vapor devices, nerve stimulation, etc would seem to indicate otherwise.
There are many potential input sources. And all of the ones you have listed rely on some output source. This proposal is focused on 2d graphics. Addressing every possible output source to which input could be made is well beyond the scope of this proposal. 2d graphical output is the dominant output source on most computing devices. As such, we've chosen to focus on that. Attempting to address every potential output source that currently exists would likely result in a proposal that was tens of thousands of pages long. Ignoring the fact that I don't work for a company that is paying me to work on this, I don't believe that it would be practical or beneficial to attempt such a proposal. We chose 2d graphics because it is both stable in terms of a front end API and the dominant method of I/O (and has been for many years).
As such, we decided to focus on output first.
Understood. But can you please provide the actual justification in the paper of why you made that choice instead of the demonstrably inaccurate one of API interdependence mentioned in 0.1.1p5? As it will avoid future arguments like this one :-)
I don't think it's demonstrably inaccurate. I assume you are referring to "Since the design of an input API is inherently reliant on the design of the output API, from the outset the authors decided to only pursue of the input API after the output API design was complete. This is why there is no proposed input API at this time." I think I overgeneralized in my past statements about this. I'll correct this now. Input, as regards to 2d graphics, only has a meaningful meaning when it corresponds to 2d graphics output.
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.
This statement worries me to no end. There are plenty of industry examples of input APIs that don't depend on the design of the output API. And I would consider such an interlocked design choice counter to well established separation of concerns design principles.
Separation of concerns is a very important design principle. That said, when user input in almost all cases has no meaning unless it is considered in terms of how it relates to the output to the user, the two are intertwined such that there are not multiple concerns.
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 must have been really tired that day as I don't remember command lists coming up :-\
Command lists were added as an indirect result of comments from one of the participants in that session. Specifically the assertion that nobody would use this API. Disregarding Bjarne's long standing position that nobody can speak for all users of C++, I considered that assertion quite a bit and the result was that I concluded that command lists, which could be offloaded to separate threads, were perhaps part of the reason that that assertion was made. And even if not, command lists serve the valuable purpose of being able to record a set of commands and submit them as needed rather than needing to modify the draw callback anytime that a change was needed. You are correct that nobody raised the issue of command lists in San Diego; after several months I came to the realization that one reason that the aforementioned assertion was made was because of the lack of a command lists feature.
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...).
Hm, I lent my copy of that one to my work library so I can't look it up right now... But sequencing of learning material doesn't correlate with API design dependence.
I was simply responded to your request for reference material in terms of sequencing output before input. I might be able to grab a few more references from my bookshelf, but if Foley and van Dam isn't persuasive, I doubt anything else would be.
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!).
It was perfectly respectful and well explained. Just doesn't address my concern. Which is essentially that what you just explained as the rational is not what's in the paper. And no worries.. many of us have been in that same adrenaline infused position :-)
Best regards,
-Mike