Forwarding my response since it didn't send it to the SG13 list for
whatever reason.

---------- Forwarded message ---------
From: Michael McLaughlin <mikebmcl_at_[hidden]>
Date: Thu, Jun 20, 2019 at 12:41 AM
Subject: Re: [SG13] 2D graphics for Cologne - P0267R9
To: Rene Rivera <grafikrobot_at_[hidden]>




On Wed, Jun 19, 2019 at 11:32 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:

> On Mon, Jun 17, 2019 at 7:33 PM Michael McLaughlin <mikebmcl_at_[hidden]>
> wrote:
>
>> 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

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