------=_Part_1042_29199484.1395341605799
Content-Type: text/plain; charset=UTF-8

I've been following the 2D graphics proposal as a game developer for some
time, which as I understand it, is a proposal to mimic Cairo's drawing api
and embed it into the standard. I can't help but wonder if we're jumping
ahead of ourselves. For the sake of discussion, I believe there are a
number of details that need to established and standardized before this
will be feasible or useful.

1. Creation of a window/display (resolution, fullscreen, etc)
2. Configuring the renderer (OpenGL, DirectX, software only)
3. Way to allow the enduser to detect input (if the 2D api lets us create a
window, how useful can it be if the user can't interact with it?)

Currently, the options for doing this are very murky. For new developers,
writing a cross platform graphical application is daunting without a
framework in place, venturing far away from core or standard C++. SDL and
Qt comes to mind as two frameworks that work with Windows, Linux, OSX, and
mobile devices for game developers and application developers respectively.
As a result, even getting a simple window to display backed by, say, an
OpenGL context is somewhat a rite of passage and requires a lot of patience
and trial and error with multiple dependencies. Traditionally, the
competing operating systems focused on their own tools for doing this for
obvious reasons but in the current software ecosystem, most developers will
need to make their creations fully cross platform, so a common API is
unlikely to foil any competitive advantage any more.

Before venturing into a 2D api, it seems to me like a lower level
abstraction would set us up better in the long run. With lower level
abstractions, this would greatly simplify existing user code in the wild
(plagued by macros and foreign function calls) and 2D drawing frameworks
would certainly crop up in the wild.

My rationale for why doing a low level window/graphics context abstraction
first makes sense:

1. For performance, developers will expect hardware acceleration and so,
the standard will need to be graphics context aware anyways
2. CAIRO is a multi-backend api for rendering to many targets (pdf, window,
png, etc) and wasn't really designed to create interactive applications
AFAIK.
3. Creation of a 2D drawing api runs the risk of being too specific to be
widely useful (i.e. a person who just wants to make a chart already has
easy options in the wild)
4. Historically, applications written using Java's 2D api needed to be
rewritten because the api didn't give the user sufficient control. In
graphics in particular, predicting what the user wants is challenging.
5. One stated application of the 2D api in the proposal is for games. But
modern 2D games need much more than a simple fixed-function drawing calls.
They may need hardware-accelerated particles, lighting, sprite sheet
handling, texture mapping, etc.

In short, my primary concern is that this proposal will make something
simple even simpler but won't make it any easier for the developer to
create the difficult things. For games in particular, I can say that if
N3888 was implemented verbatim, I probably would not use it in any of my
personal projects and I would venture to claim that many other game
developers would eschew it as well. There is a reason fixed-function
pipelines were rendered obsolete. They simply do not afford the programmer
enough flexibility and the programming model is "incorrect" in that it
doesn't mirror well what is happening fundamentally in a rendering
pipeline. The proposal *does* make an effort to consider the various
platforms (see "GPU Resource Management in Various Technologies"), but it
would appear that all of that work to unify the api across platforms would
be opaque to the programmer. In contrast, if by some miracle, the first 3
points I mentioned above *were* standardized, it would be immediately
useful to everybody and many different frameworks for a variety of uses
would most certainly crop up immediately as a result.

Cheers,
Jeremy

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1042_29199484.1395341605799
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I've been following the 2D graphics proposal as a game dev=
eloper for some time, which as I understand it, is a proposal to mimic Cair=
o's drawing api and embed it into the standard. I can't help but wonder if =
we're jumping ahead of ourselves. For the sake of discussion, I believe the=
re are a number of details that need to established and standardized before=
 this will be feasible or useful.<div><br></div><div>1. Creation of a windo=
w/display (resolution, fullscreen, etc)</div><div>2. Configuring the render=
er (OpenGL, DirectX, software only)</div><div>3. Way to allow the enduser t=
o detect input (if the 2D api lets us create a window, how useful can it be=
 if the user can't interact with it?)</div><div><br></div><div>Currently, t=
he options for doing this are very murky. For new developers, writing a cro=
ss platform graphical application is daunting without a framework in place,=
 venturing far away from core or standard C++. SDL and Qt comes to mind as =
two frameworks that work with Windows, Linux, OSX, and mobile devices for g=
ame developers and application developers respectively. As a result, even g=
etting a simple window to display backed by, say, an OpenGL context is some=
what a rite of passage and requires a lot of patience and trial and error w=
ith multiple dependencies. Traditionally, the competing operating systems f=
ocused on their own tools for doing this for obvious reasons but in the cur=
rent software ecosystem, most developers will need to make their creations =
fully cross platform, so a common API is unlikely to foil any competitive a=
dvantage any more.</div><div><br></div><div>Before venturing into a 2D api,=
 it seems to me like a lower level abstraction would set us up better in th=
e long run. With lower level abstractions, this would greatly simplify exis=
ting user code in the wild (plagued by macros and foreign function calls) a=
nd 2D drawing frameworks would certainly crop up in the wild.</div><div><br=
></div><div>My rationale for why doing a low level window/graphics context =
abstraction first makes sense:</div><div><br></div><div>1. For performance,=
 developers will expect hardware acceleration and so, the standard will nee=
d to be graphics context aware anyways</div><div>2. CAIRO is a multi-backen=
d api for rendering to many targets (pdf, window, png, etc) and wasn't real=
ly designed to create interactive applications AFAIK.</div><div>3. Creation=
 of a 2D drawing api runs the risk of being too specific to be widely usefu=
l (i.e. a person who just wants to make a chart already has easy options in=
 the wild)</div><div>4. Historically, applications written using Java's 2D =
api needed to be rewritten because the api didn't give the user sufficient =
control. In graphics in particular, predicting what the user wants is chall=
enging.</div><div>5. One stated application of the 2D api in the proposal i=
s for games. But modern 2D games need much more than a simple fixed-functio=
n drawing calls. They may need hardware-accelerated particles, lighting, sp=
rite sheet handling, texture mapping, etc.</div><div><br></div><div>In shor=
t, my primary concern is that this proposal will make something simple even=
 simpler but won't make it any easier for the developer to create the diffi=
cult things. For games in particular, I can say that if N3888 was implement=
ed verbatim, I probably would not use it in any of my personal projects and=
 I would venture to claim that many other game developers would eschew it a=
s well. There is a reason fixed-function pipelines were rendered obsolete. =
They simply do not afford the programmer enough flexibility and the program=
ming model is "incorrect" in that it doesn't mirror well what is happening =
fundamentally in a rendering pipeline. The proposal *does* make an effort t=
o consider the various platforms (see "GPU Resource Management in Various T=
echnologies"), but it would appear that all of that work to unify the api a=
cross platforms would be opaque to the programmer. In contrast, if by some =
miracle, the first 3 points I mentioned above *were* standardized, it would=
 be immediately useful to everybody and many different frameworks for a var=
iety of uses would most certainly crop up immediately as a result.</div><di=
v><br></div><div>Cheers,<br>Jeremy</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1042_29199484.1395341605799--

.

------=_Part_163_17389440.1395659216944
Content-Type: text/plain; charset=UTF-8

On Thursday, March 20, 2014 7:53:25 PM UTC+1, Jeremiah Ong wrote:
>
> I've been following the 2D graphics proposal as a game developer for some
> time, which as I understand it, is a proposal to mimic Cairo's drawing api
> and embed it into the standard. I can't help but wonder if we're jumping
> ahead of ourselves. For the sake of discussion, I believe there are a
> number of details that need to established and standardized before this
> will be feasible or useful.
>
> 1. Creation of a window/display (resolution, fullscreen, etc)
> 2. Configuring the renderer (OpenGL, DirectX, software only)
> 3. Way to allow the enduser to detect input (if the 2D api lets us create
> a window, how useful can it be if the user can't interact with it?)
>

A 2D drawing API can be used outside of a GUI, no? I happen to have
recently needed to produce PNG output from a non-interactive command-line
tool. All of the details claimed here as necessary to make this useful
would have seemed completely useless to me. The 2D drawing bits by
themselves would have seemed extremely useful. *shrug*

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_163_17389440.1395659216944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 20, 2014 7:53:25 PM UTC+1, Jeremiah Ong=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I've b=
een following the 2D graphics proposal as a game developer for some time, w=
hich as I understand it, is a proposal to mimic Cairo's drawing api and emb=
ed it into the standard. I can't help but wonder if we're jumping ahead of =
ourselves. For the sake of discussion, I believe there are a number of deta=
ils that need to established and standardized before this will be feasible =
or useful.<div><br></div><div>1. Creation of a window/display (resolution, =
fullscreen, etc)</div><div>2. Configuring the renderer (OpenGL, DirectX, so=
ftware only)</div><div>3. Way to allow the enduser to detect input (if the =
2D api lets us create a window, how useful can it be if the user can't inte=
ract with it?)</div></div></blockquote><div><br>A 2D drawing API can be use=
d outside of a GUI, no? I happen to have recently needed to produce PNG out=
put from a non-interactive command-line tool. All of the details claimed he=
re as necessary to make this useful would have seemed completely useless to=
 me. The 2D drawing bits by themselves would have seemed extremely useful. =
*shrug*<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_163_17389440.1395659216944--

.

On Mon, Mar 24, 2014 at 4:06 AM, R. Martinho Fernandes
<martinho.fernandes@gmail.com> wrote:
> On Thursday, March 20, 2014 7:53:25 PM UTC+1, Jeremiah Ong wrote:
>>
>> I've been following the 2D graphics proposal as a game developer for some
>> time, which as I understand it, is a proposal to mimic Cairo's drawing api
>> and embed it into the standard. I can't help but wonder if we're jumping
>> ahead of ourselves. For the sake of discussion, I believe there are a number
>> of details that need to established and standardized before this will be
>> feasible or useful.
>>
>> 1. Creation of a window/display (resolution, fullscreen, etc)
>> 2. Configuring the renderer (OpenGL, DirectX, software only)
>> 3. Way to allow the enduser to detect input (if the 2D api lets us create
>> a window, how useful can it be if the user can't interact with it?)
>
>
> A 2D drawing API can be used outside of a GUI, no? I happen to have recently
> needed to produce PNG output from a non-interactive command-line tool. All
> of the details claimed here as necessary to make this useful would have
> seemed completely useless to me. The 2D drawing bits by themselves would
> have seemed extremely useful. *shrug*
>

A 2D drawing API or any drawing API needs a backend. In your case, you
needed a png backend which is simple enough with libpng, libSDL_Image,
or libSOIL or what have you. You are sort of cherry picking concepts
from my email. My larger point was touching on the fact that the
proposal mentioned games and game developers as a target audience so I
was writing from that perspective. In addition, my point later on is
that if all you wanted to do was draw some things and make an image or
something non-interactive, this is something already easy with
existing libraries. My main criticism of the proposal is that it makes
already simple things simpler, while ignoring the harder bits. *shrug*
/s

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.