By popular demand, a counterproposal to P0267

[Jeremy Ong]

Hello SG13,

My name is Jeremy and I am the CTO of a startup which builds a large-scale chat application with heavy client and server-side complexity. C++ is used heavily, albeit predominantly on the backend for scaling to hundreds of thousands of users. Formerly, I was a graphics engine developer, working on MMOs, but also games you have likely played before if you're a PC gamer. C++ is the lingua franca in this space, and I've personally written a number of home-grown renderers for experimentation purposes, but also just for fun to explore APIs such as Vulkan, Metal, D3D12, and OpenGL, SDL, and other such libraries before that. Graphics was what got me into C++ in the first place, now over 14 years ago, and I was heavily inspired by early work done in games such as Doom and Starcraft. I started on the fixed function OpenGL 2.0 pipeline while simultaneously getting acquainted with QT. I've also written some low level code that performs layout rendering, and interfaced with window managers such as X11 and the Windows system.

Basically, I've been around the block a fair bit, and have been encouraged (in a Reddit thread no less: https://www.reddit.com/r/cpp/comments/7z50oa/batteries_not_included_what_should_go_in_the_c/) to express my lack of enthusiasm for this proposal here.

The goal as stated by the proposal is as follows: "The audience for this technology consists of developers who need to render or display 2D graphics, regardless of what type (games or other)."

I am writing to express a professional opinion that this proposal and implementation will not service the stated goals. It is widely unsuitable for games, will be a constant thorn in the side of the standards committee, and will need to co-evolve with other existing open standards (OpenGL, Vulkan) as hardware changes are made.

1. Cairo as a basis is misguided.

As a quick note: the proposal erroneously states that Firefox uses it, however, Firefox already switched off of it to https://skia.org/ in March of last year (Firefox 52). Skia is also used for Android and Chrome OS. That aside however, I believe this is a completely backwards choice in the modern era, suitable primarily for people who want to relive the old days of how we used to think about "graphics." Historically, C++ standards evolved by starting with lower level abstractions and bubbling up to accommodate more functionality. This holistic approach allows implementers to leverage preexisting standards and mechanisms. It also allows new implementations to surface in the wild (e.g. Boost) for further consideration and real-world testing.

Cairo skips too many steps. With it, you bring in all this baggage regarding image formats, window surfaces, GPU contexts, and more in a SINGLE proposal. Better is to independently decide for each such decision what our stance is, release something, and then iterate. Cairo is "battle tested" in the sense that people have used it for a while, strictly for 2D things, NOT for games (a stated goal?), and people are ready to move on from it to something more modern. Bundling all of it together is high risk, and an implementer's worst nightmare. As far as a standard goes, do we really want to bring in a large dependency that is already on the cusp of deprecation? As far as I can tell, the industry is moving past using such libraries in order to better take advantage of the hardware (CSS transforms/transitions are hardware accelerated, Android is leveraging more OpenGLES capabilities directly, etc).

2. This library is far too opinionated on how UI should be done

Painting to a canvas is a very specific high level abstraction for presenting graphical elements to the end user. Starting here, again, skips too many steps. Sometimes you want a bezier curve, but other times for performance, a mipmapped texture works far better and provides more flexibility. The library has opinions on colors, memory sizing, fonts, and more. If we want to tackle these things correctly, going slower and providing incremental value to engine/library developers will get us to a better place. Even for 2D, font rendering can be surprisingly tricky (games often use signed distance textures to prevent bad aliasing). For rendering many glyphs in large unicode fonts, library implementers have to be aware of various tradeoffs, or more likely than not, present the user with a less-than-desirable result with no recourse to actually fix it.

3. The library is underspecified

The parts that are hard but critical (window surface, choice of driver backend, input) are vastly underspecified. It turns out, these are the things that are useful to standardize! The biggest value that additions to the C++ standard library provides is when I as a programmer can do something that I know works on all platforms and saves me time. The <atomic> and <thread> primitives are great examples of this. They did the upfront hard work of identifying an abstraction for memory ordering models on all sorts of different architectures, and presents a unified cross-platform API that is both robust and practical. Simply fantastic. In contrast, here we have a lot of geometry and color spaces that is comparatively an easier problem. This is backwards. Problems should be tackled in order of difficulty and highest risk.

4. Performance is a concern

C++ as a language is, for better or worse, largely designed to facilitate programming a CPU, aka some processing unit that is branchy, smart, and moderately parallelizable. The GPU, conversely, hates branches, has limited registers/ALU operators, and is heavily parallel. The proposal recognizes to a certain degree that submission of data to the GPU can be slow, and synchronization is likely to lead to stalls on either the CPU or the GPU. However, the fundamental problem here is that the job of the CPU is to queue and submit work to the GPU (in a way that doesn't violate memory constraints). In the case of this proposal, it feels like we are overreaching beyond the general purpose nature of the programming language, and should instead, seek to interoperate with other GPU programming constructs more.

5. I can modify a library, a standard not so much

There are a plethora of libraries that provide the functionality this proposal includes. QT, cairo, fog, skia, IMGUI, SDL, SFML, and more. Granted there are different paradigms here, and we need to mix paradigms, but the same is true for other languages. What's important is that if the library doesn't do what I want, I can modify it easily and swiftly. I can read the source code for my particular platform, and identify why there's a bottleneck. The above tools may even provide tracers or tools to profile performance or debug artifacts. If a new capability is released for some platform, they can be expected to update reasonably quickly with support for that capability. Can the same be said for a standard which needs to ship to all platforms simultaneously?

Conclusion:

I think the idea of a "Graphics" subcommittee is great. Graphics and C++ are already intricately joined at the hip, and programmers all over the world operate at an insanely sophisticated level to do amazing things with C++. Addressing it in this way, however, feels misguided, and it feels likely that if this were to ship, there would be a fair bit of regret. Problems I think are worth tackling:

1. An abstraction around a vulkan context and OpenGL context. Why not? Vulkan and OpenGL are open standards, widely compatible, and we can provide a compile time check so the user can determine if it's available or not. At runtime, it can be used to query for valid gfx devices and provide a context if possible. It should be thin and devolve to the vulkan/OpenGL headers as soon as possible, but this interoperability would drastically lower the barrier to doing all sorts of things (as a kid, I would have loved this instead of wrangling with OpenGL extension pointers and proc addresses). For the engine developers that need support for a non-Vulkan/OpenGL context, they already know how to do that, but again, this lowers the barrier.

2. Texture/image formats. This area is an actual problem in the industry that is difficult to deal with and also lies in a grey area between the CPU/GPU. Different formats compress better for different types of data (alpha, no alpha, normal map, specular map, font, etc). Reading data and writing data in some set of interchange formats that are natively supported by most hardware with fallback conversions for others would be incredibly useful.

3. Graphics related operations on the CPU that would benefit from a standard existing. I'm thinking SIMD, AVX, usage of ultra-wide registers, etc which could in turn be leveraged in a library like Eigen or BLAS. Minimally, I could see these operators intermingling with standard graphics pipelines or compute pipelines.

4. Handling OS events (window resize, position change, mouse input events, keyboard events, multi-text input for unicode, etc), with extension ranges for platform specific events. Managing the OS event loops in a cross platform way is a huge hassle but abstractions exist that are ossified enough that I think a standard around it would provide real value (that doesn't depreciate too quickly).

Thanks for reading,

Jeremy

[Nevin Liber]

On Fri, Feb 23, 2018 at 4:23 PM, Jeremy Ong <jer...@plexchat.com> wrote:

Conclusion:

I think the idea of a "Graphics" subcommittee is great. Graphics and C++ are already intricately joined at the hip, and programmers all over the world operate at an insanely sophisticated level to do amazing things with C++. Addressing it in this way, however, feels misguided, and it feels likely that if this were to ship, there would be a fair bit of regret. Problems I think are worth tackling:

1. An abstraction around a vulkan context and OpenGL context. Why not? Vulkan and OpenGL are open standards, widely compatible, and we can provide a compile time check so the user can determine if it's available or not. At runtime, it can be used to query for valid gfx devices and provide a context if possible. It should be thin and devolve to the vulkan/OpenGL headers as soon as possible, but this interoperability would drastically lower the barrier to doing all sorts of things (as a kid, I would have loved this instead of wrangling with OpenGL extension pointers and proc addresses). For the engine developers that need support for a non-Vulkan/OpenGL context, they already know how to do that, but again, this lowers the barrier.

2. Texture/image formats. This area is an actual problem in the industry that is difficult to deal with and also lies in a grey area between the CPU/GPU. Different formats compress better for different types of data (alpha, no alpha, normal map, specular map, font, etc). Reading data and writing data in some set of interchange formats that are natively supported by most hardware with fallback conversions for others would be incredibly useful.

3. Graphics related operations on the CPU that would benefit from a standard existing. I'm thinking SIMD, AVX, usage of ultra-wide registers, etc which could in turn be leveraged in a library like Eigen or BLAS. Minimally, I could see these operators intermingling with standard graphics pipelines or compute pipelines.

4. Handling OS events (window resize, position change, mouse input events, keyboard events, multi-text input for unicode, etc), with extension ranges for platform specific events. Managing the OS event loops in a cross platform way is a huge hassle but abstractions exist that are ossified enough that I think a standard around it would provide real value (that doesn't depreciate too quickly).

Note:  I have no stake in this. 

None of the above is a proposal.  Where are the papers?  Who is committing to champion them?  Has anybody implemented it?  Etc., etc.

SD-4: WG21 Practices and Procedures: "Delay vs. bird in the hand. We cannot act on ideas without papers, and we do not significantly delay progress on concrete proposals in order to wait for alternative proposals we might get in the future."

P0267, or in its previous incarnation, n4073, has been in progress for almost four years.  Counterproposals are welcome, but they have to be more than emails of wish lists of work you are hoping people will go out and volunteer to do.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[Jeremy Ong]

On Fri, Feb 23, 2018 at 4:05 PM, Nevin Liber <ne...@eviloverlord.com> wrote:

On Fri, Feb 23, 2018 at 4:23 PM, Jeremy Ong <jer...@plexchat.com> wrote:

Conclusion:

I think the idea of a "Graphics" subcommittee is great. Graphics and C++ are already intricately joined at the hip, and programmers all over the world operate at an insanely sophisticated level to do amazing things with C++. Addressing it in this way, however, feels misguided, and it feels likely that if this were to ship, there would be a fair bit of regret. Problems I think are worth tackling:

1. An abstraction around a vulkan context and OpenGL context. Why not? Vulkan and OpenGL are open standards, widely compatible, and we can provide a compile time check so the user can determine if it's available or not. At runtime, it can be used to query for valid gfx devices and provide a context if possible. It should be thin and devolve to the vulkan/OpenGL headers as soon as possible, but this interoperability would drastically lower the barrier to doing all sorts of things (as a kid, I would have loved this instead of wrangling with OpenGL extension pointers and proc addresses). For the engine developers that need support for a non-Vulkan/OpenGL context, they already know how to do that, but again, this lowers the barrier.

2. Texture/image formats. This area is an actual problem in the industry that is difficult to deal with and also lies in a grey area between the CPU/GPU. Different formats compress better for different types of data (alpha, no alpha, normal map, specular map, font, etc). Reading data and writing data in some set of interchange formats that are natively supported by most hardware with fallback conversions for others would be incredibly useful.

3. Graphics related operations on the CPU that would benefit from a standard existing. I'm thinking SIMD, AVX, usage of ultra-wide registers, etc which could in turn be leveraged in a library like Eigen or BLAS. Minimally, I could see these operators intermingling with standard graphics pipelines or compute pipelines.

4. Handling OS events (window resize, position change, mouse input events, keyboard events, multi-text input for unicode, etc), with extension ranges for platform specific events. Managing the OS event loops in a cross platform way is a huge hassle but abstractions exist that are ossified enough that I think a standard around it would provide real value (that doesn't depreciate too quickly).

Note:  I have no stake in this. 

None of the above is a proposal.  Where are the papers?  Who is committing to champion them?  Has anybody implemented it?  Etc., etc.

Nobody is working on those. I only offer it primarily as a suggestion for a more productive starting point. It is implemented in the form of libraries mentioned above.

 

SD-4: WG21 Practices and Procedures: "Delay vs. bird in the hand. We cannot act on ideas without papers, and we do not significantly delay progress on concrete proposals in order to wait for alternative proposals we might get in the future."

If people want to bulldoze ahead in spite of professionally stated opinions to the contrary, fine. However, I don't agree with this principle from a pragmatic standpoint. Having a concrete vision is important, and it is precisely the vision for this working group that I have misgivings toward. Certainly the merits of the proposal need to be considered, no matter how "concrete" it is. Personally, I don't like the idea of any compiler authorship group laboring against how to more efficiently rasterize vector graphics on their platforms. MacOS can't even ship C++17 for crying out loud.

 

P0267, or in its previous incarnation, n4073, has been in progress for almost four years.  Counterproposals are welcome, but they have to be more than emails of wish lists of work you are hoping people will go out and volunteer to do.

Yes it's been in progress for four years, and frankly, I'm not convinced it's been subject to enough rigor from the right people. Late feedback is annoying and suboptimal, but I'm not sure what other recourse there was.

I don't care if nobody works on what I've suggested. I'm saying that if we were going to work on it, we're better of starting with a smaller scope and at a lower level abstraction and building upwards. I think this proposal will do more harm than good, fragment compilers/platforms more instead of bringing them together, and waste unnecessary cycles that could be productively spent working on other initiatives.

- Jeremy

 

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "SG13 - HMI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sg13+uns...@isocpp.org.
To post to this group, send email to sg...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/sg13/.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/sg13/CAGg_6%2BPMsASwZ8UTk56a-rgTiBcr020i2HJVK-61KFpQFNYmbw%40mail.gmail.com.

[Klaim - Joël Lamotte]

Hi, let me be an advocate for the paper (or at least it's premise) and try to debunk these arguments that I

read everywhere and that I always qualify as "missing the point".

I didn't intend to do this at first but maybe this will clarify some things to other people.

(note: I am not against a rebutal, I am just against false arguments on something misunderstood)

(also this is a rant about the rants about this proposal)

On 23 February 2018 at 23:23, Jeremy Ong <jer...@plexchat.com> wrote:

Hello SG13,

My name is Jeremy and I am the CTO of a startup which builds a large-scale chat application with heavy client and server-side complexity. C++ is used heavily, albeit predominantly on the backend for scaling to hundreds of thousands of users. Formerly, I was a graphics engine developer, working on MMOs, but also games you have likely played before if you're a PC gamer. C++ is the lingua franca in this space, and I've personally written a number of home-grown renderers for experimentation purposes, but also just for fun to explore APIs such as Vulkan, Metal, D3D12, and OpenGL, SDL, and other such libraries before that. Graphics was what got me into C++ in the first place, now over 14 years ago, and I was heavily inspired by early work done in games such as Doom and Starcraft. I started on the fixed function OpenGL 2.0 pipeline while simultaneously getting acquainted with QT. I've also written some low level code that performs layout rendering, and interfaced with window managers such as X11 and the Windows system.

Basically, I've been around the block a fair bit, and have been encouraged (in a Reddit thread no less: https://www.reddit.com/r/cpp/comments/7z50oa/batteries_not_included_what_should_go_in_the_c/) to express my lack of enthusiasm for this proposal here.

The goal as stated by the proposal is as follows: "The audience for this technology consists of developers who need to render or display 2D graphics, regardless of what type (games or other)."

As stated by Nevin, this is not a proposal. This is an email giving your opinion. You could have put this in an opinion document sent through the proposal submission, that would have more chance

to trigger a discussion in the committee (from what I understand). Like the proposal to not accept the "constexpr if" proposal from Alexandrescu.

Howver in the present case, it would not have been sufficient to just argue against the principles without at least:

   1. a specific issue leading to not making this proposal implementable or leading to more issues (the arguments you give here are not strong enough, in my opinion).

   2. a proposed alternative. You kind of suggest one but you currently are not propsing one. You could. Also as there is an impementation

       of the current proposal, you would need, I believe, also an implementation (even if not finished) to have an actual pressure against the current one.

       I am assuming this after following, for example, several counter proposals to the major coroutine one are simply not implemented so most of their arguments

       are very difficult to actually test or experience.

 

I am writing to express a professional opinion that this proposal and implementation will not service the stated goals.

To me it seems it will, but it will not service goals of the majority of graphics progammers, who tend to assume that high performance graphics is the only way to go.

And also ignore scientifics, statisticians, modern beginners and a whole lot of other people who don't really need to know OGL or Vulkan to draw their graphics.

 

It is widely unsuitable for games,

Depends on the game, really. Although the majority of commercial games will probably not use such interface, indeed.

That is beside the point.

 

will be a constant thorn in the side of the standards committee, and will need to co-evolve with other existing open standards (OpenGL, Vulkan) as hardware changes are made.

What is the problem here?

A standard can be implementd whatever they want. They can just put a graphic engine already existing (even the OS API) behind the standard interface.

It's not more maintenance than, say, filesytem.

 

1. Cairo as a basis is misguided.

As a quick note: the proposal erroneously states that Firefox uses it, however, Firefox already switched off of it to https://skia.org/ in March of last year (Firefox 52). Skia is also used for Android and Chrome OS. That aside however, I believe this is a completely backwards choice in the modern era, suitable primarily for people who want to relive the old days of how we used to think about "graphics." Historically, C++ standards evolved by starting with lower level abstractions and bubbling up to accommodate more functionality. This holistic approach allows implementers to leverage preexisting standards and mechanisms. It also allows new implementations to surface in the wild (e.g. Boost) for further consideration and real-world testing.

Cairo was the starting point. I am not sure the current proposal still matches it, though in the big picture it certainly kept it's high-level concepts.

That you can also find in Cinder and other similar framework, including custom drawing in Qt.

 

Cairo skips too many steps. With it, you bring in all this baggage regarding image formats, window surfaces, GPU contexts, and more in a SINGLE proposal.

I kind of agree with the "one proposal acting as several" point. However, no proposal have been proposed so far to provide the different parts on which a proposal

to draw on a surface could be built over.

That is, I believe that if such proposals (2D/3D geometry with graphics in mind(or not), image representation, etc.) existed and were working on, the drawing proposal

would not need to be that big and would rely on that work. As currently there is not enough people to make these proposals and the end goal is doable

with the current ones, 

 

Better is to independently decide for each such decision what our stance is, release something, and then iterate. Cairo is "battle tested" in the sense that people have used it for a while, strictly for 2D things, NOT for games (a stated goal?), and people are ready to move on from it to something more modern. Bundling all of it together is high risk, and an implementer's worst nightmare. As far as a standard goes, do we really want to bring in a large dependency that is already on the cusp of deprecation? As far as I can tell, the industry is moving past using such libraries in order to better take advantage of the hardware (CSS transforms/transitions are hardware accelerated, Android is leveraging more OpenGLES capabilities directly, etc).

The proposal evolved enough to be a common ground for several possible implementations. It might need to be fixed more.

Please provide concrete points (citing the proposal paragraphs) that  will be problematic and write this in an actual paper.

 

2. This library is far too opinionated on how UI should be done

Note that, as said before, there is only one opinion that have been technically proposed and argued about so far.

You seem to be close to provide your own proposal and I think it would be welcome (because of your stated experience), at least as a counterpoint.

Until then, yes there is only one opininiated paper and nobody has really gone against it with an alternative proposal.

 

Painting to a canvas is a very specific high level abstraction for presenting graphical elements to the end user. Starting here, again, skips too many steps. Sometimes you want a bezier curve, but other times for performance, a mipmapped texture works far better and provides more flexibility. The library has opinions on colors, memory sizing, fonts, and more. If we want to tackle these things correctly, going slower and providing incremental value to engine/library developers will get us to a better place. Even for 2D, font rendering can be surprisingly tricky (games often use signed distance textures to prevent bad aliasing). For rendering many glyphs in large unicode fonts, library implementers have to be aware of various tradeoffs, or more likely than not, present the user with a less-than-desirable result with no recourse to actually fix it.

Font rendering and unicode related stuffs are not currently proposed, they just open the door for rendering them and don't specify anything.

See section 10 in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0267r7.pdf

"10 Text rendering and display [io2d.text] 1

 [ Note: Text rendering and matters related to it, such as font support, will be added at a later date. This section is a placeholder. 

The integration of text rendering is expected to result in the addition of member functions to the surface class and changes to other parts of the text. — end note ] "

If you make a proposal about text rendering, this section could be removed and replaced by relying on your proposal.

 

3. The library is underspecified

The parts that are hard but critical (window surface, choice of driver backend, input) are vastly underspecified. It turns out, these are the things that are useful to standardize! The biggest value that additions to the C++ standard library provides is when I as a programmer can do something that I know works on all platforms and saves me time. The <atomic> and <thread> primitives are great examples of this. They did the upfront hard work of identifying an abstraction for memory ordering models on all sorts of different architectures, and presents a unified cross-platform API that is both robust and practical. Simply fantastic. In contrast, here we have a lot of geometry and color spaces that is comparatively an easier problem. This is backwards. Problems should be tackled in order of difficulty and highest risk.

You will have to be more precise than "vastly underspecified" to help here. What exactly in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0267r7.pdf

is underspecified, how is it a problem, what do you propose to do about this. Put the answer in a document and send it so that it helps.

 

4. Performance is a concern

C++ as a language is, for better or worse, largely designed to facilitate programming a CPU, aka some processing unit that is branchy, smart, and moderately parallelizable. The GPU, conversely, hates branches, has limited registers/ALU operators, and is heavily parallel. The proposal recognizes to a certain degree that submission of data to the GPU can be slow, and synchronization is likely to lead to stalls on either the CPU or the GPU. However, the fundamental problem here is that the job of the CPU is to queue and submit work to the GPU (in a way that doesn't violate memory constraints). In the case of this proposal, it feels like we are overreaching beyond the general purpose nature of the programming language, and should instead, seek to interoperate with other GPU programming constructs more.

As the goal is to give enough performance to draw with decent framerate dynamic stuffs on a surface, I believ that your experience might be lisleading.

For example, nobody in the graphic rendering world now consider something like Dear IMGU to be a problem performance rendering-wise even if it's used in the worst conditions.

Nothing prevent the current drawing interface from using the same caching techniques than Dear IMGUI behind a simple drawing interface.

As soon as you want high performance, you almost always will end up not using the standard anyway. That's true for thread (which don't have yet all the options necessary to customize affinity for example),

for filesystem, for timing (chrono is good but lack some guarantees) etc. Same for graphics.

But the current implementation of p0267r7 might be enough for most of the intended usage that is "default" graphic display tool that don't need any setup.

 

5. I can modify a library, a standard not so much

There are a plethora of libraries that provide the functionality this proposal includes. QT, cairo, fog, skia, IMGUI, SDL, SFML, and more. Granted there are different paradigms here, and we need to mix paradigms, but the same is true for other languages. What's important is that if the library doesn't do what I want, I can modify it easily and swiftly. I can read the source code for my particular platform, and identify why there's a bottleneck. The above tools may even provide tracers or tools to profile performance or debug artifacts. If a new capability is released for some platform, they can be expected to update reasonably quickly with support for that capability. Can the same be said for a standard which needs to ship to all platforms simultaneously?

Are you arguing that you can't modify a standard library?

That's already the case with everything it provides (as you lose all guarantees if you try to do so).

I don't understand how that would be solved by not providing a library.

By the way I am surprised that you did not invoke the need for a dependency manager tool as a solution against this proposal.

I will add on this now as I think it's important to address:

an additional tool to learn (however simple it is) is inacceptable in teaching context and makes things harder than necessary in other contexts where you just want to draw something.

A common example is graphic visualisation of scientific data which only need to be rendered once. A lot of my coworkers do that in python because it's simpler (without using pip),

but the initial data computation could have been (massively) faster in C++.

Trust me when I say they don't like to have to know about a build system either.

Having to know another library, another dependency manager tool (because let's face it,

none in particular will be standardized, although an interface to one could be specified), another build system

is always more cost (aka time and memory) to spend than using the default tool provided everywhere you use the same language.

Most arguments about this are assuming that a dependency manager would replace a default standard library.

In my opinion, it would solve a different problem.

Of course a dependency tool would help massively most industrial or non-trivial complex projects.

I don't think it's the same context than what this proposal is anchored in.

 

Conclusion:

I think the idea of a "Graphics" subcommittee is great.

This is the Human-Machine Interface commitee. Are you suggesting to create a graphic-specific one?

 

Graphics and C++ are already intricately joined at the hip, and programmers all over the world operate at an insanely sophisticated level to do amazing things with C++. Addressing it in this way, however, feels misguided, and it feels likely that if this were to ship, there would be a fair bit of regret. Problems I think are worth tackling:

Note that I don't understant this sentence as currently mostly engine programmers (which do not use the standard, to be short) will associate C++ and graphics rendering.

The others will simply use Unity or something higher level, just to avoid all the non-programming issues we have with C++.

 

1. An abstraction around a vulkan context and OpenGL context. Why not? Vulkan and OpenGL are open standards, widely compatible, and we can provide a compile time check so the user can determine if it's available or not. At runtime, it can be used to query for valid gfx devices and provide a context if possible. It should be thin and devolve to the vulkan/OpenGL headers as soon as possible, but this interoperability would drastically lower the barrier to doing all sorts of things (as a kid, I would have loved this instead of wrangling with OpenGL extension pointers and proc addresses). For the engine developers that need support for a non-Vulkan/OpenGL context, they already know how to do that, but again, this lowers the barrier.

That would be a great idea!

However:

1. That would require writting a proposal. And probably at least one demo implementation.

2. That have nothing to do with simple drawing on a surface. If you meant that it would be the brick on which to rely upon to build a simple drawing library, then yes, why not.

    Ït does not exist today and does not solve the initial problem (a simple and decently efficient way to draw something on a "surface").

    I know what a "display hello world on the screen" program looks like with the proposal versus with with OGL and Vulkan. If the goal is teaching or anything beside implementing a rendering tool,

    I chose p0267 definitely. That will avoid angry face from students and science based coworkers.

2. Texture/image formats. This area is an actual problem in the industry that is difficult to deal with and also lies in a grey area between the CPU/GPU. Different formats compress better for different types of data (alpha, no alpha, normal map, specular map, font, etc). Reading data and writing data in some set of interchange formats that are natively supported by most hardware with fallback conversions for others would be incredibly useful.

Great, that would be a wonderful proposal I think. Although I don't know about the potential licencing issues.

Anyway I think anyone here would be pleased to have such proposal written and submitted.

 

3. Graphics related operations on the CPU that would benefit from a standard existing. I'm thinking SIMD, AVX, usage of ultra-wide registers, etc which could in turn be leveraged in a library like Eigen or BLAS. Minimally, I could see these operators intermingling with standard graphics pipelines or compute pipelines.

That's already worked-on and clearly intended as not-being-the-same-subject-as-p0267 by SG14, SG1 and maybe some other people.

See the following proposals (among others):

 - SIMD support: P0214, P0916, P0918, P0964, etc.

 - Executor (required as first step into heterogeneous computing): P0443, P0761 and some other related to their usage in the future standard library

 - Heterogenous Computing: P0796

 

4. Handling OS events (window resize, position change, mouse input events, keyboard events, multi-text input for unicode, etc), with extension ranges for platform specific events. Managing the OS event loops in a cross platform way is a huge hassle but abstractions exist that are ossified enough that I think a standard around it would provide real value (that doesn't depreciate too quickly).

That's basically the premise of some input library. I am working on one (but I don't think I'm expert enough so it's a bit messy) more focused on input devices easily and using them.

If you want to propose one focused on platform events, this is the good place, it would be a good complement.

There is already one in flight but I don't know it's status.

However if you want it to support unicode, work on unicode related tools (like "text" handling, Unicode conversion functions etc.) would be a first requirement I believe,

for the drawing proposal too (which is one of the reason it does not provide anything, just a placeholder chapter for drawing these).

 

Thanks for reading,

Jeremy

--
You received this message because you are subscribed to the Google Groups "SG13 - HMI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sg13+uns...@isocpp.org.
To post to this group, send email to sg...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/sg13/.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/sg13/efb3ba0b-3c84-4f46-b7dc-5c8fcb5402b7%40isocpp.org.

[Klaim - Joël Lamotte]

On 24 February 2018 at 05:41, Jeremy Ong <jer...@plexchat.com> wrote:

On Fri, Feb 23, 2018 at 4:05 PM, Nevin Liber <ne...@eviloverlord.com> wrote:

None of the above is a proposal.  Where are the papers?  Who is committing to champion them?  Has anybody implemented it?  Etc., etc.

Nobody is working on those. I only offer it primarily as a suggestion for a more productive starting point. It is implemented in the form of libraries mentioned above.

 

Ok but you do know that nothing is officially proposed or discussed (opinions can be discussed if they raise clear points) without a paper (a specific document)

that is submitted through the right channels? Otherwise your opinion will be probably lost.

 

SD-4: WG21 Practices and Procedures: "Delay vs. bird in the hand. We cannot act on ideas without papers, and we do not significantly delay progress on concrete proposals in order to wait for alternative proposals we might get in the future."

If people want to bulldoze ahead in spite of professionally stated opinions to the contrary, fine.

How is that helpful?

 

However, I don't agree with this principle from a pragmatic standpoint. 

Having a concrete vision is important, and it is precisely the vision for this working group that I have misgivings toward. Certainly the merits of the proposal need to be considered, no matter how "concrete" it is. Personally, I don't like the idea of any compiler authorship group laboring against how to more efficiently rasterize vector graphics on their platforms. MacOS can't even ship C++17 for crying out loud.

 

I think you misunderstand.

The point is that you need an actual paper, not that your opinion will be ignored.

Just put some concrete poitns in a paper, send it and that's done. Of course it will not be discussed if it does not have a clear point, but the issue here

is that an opinion email does not exist in the standard system.

aka this, is not what we call here a proposal.

Put again another way, nobody can officially comment, rely upon, or implement something else than a paper proposing some specific interface or poining specific issues.

Also, nothing prevent a specific "vision" to get in the standard, look at the networking proposal it's basically the pov of only one person (the ASIO author).

The commitee will just give it's feedback, fix and tweak a few things to make it more workable (and bikeshed on names).

It does not really design by itself, it merely modify an oriignal vision.

So if you write a proposal for a better solution, it might be rejected or modified and included.

 

P0267, or in its previous incarnation, n4073, has been in progress for almost four years.  Counterproposals are welcome, but they have to be more than emails of wish lists of work you are hoping people will go out and volunteer to do.

Yes it's been in progress for four years, and frankly, I'm not convinced it's been subject to enough rigor from the right people. Late feedback is annoying and suboptimal, but I'm not sure what other recourse there was.

Well you could have written your piece in a file and send it as a proposal that woudl have been a clear feedback and maybe discussed in the committee (and maybe rejected, maybe something else).

If my memory is correct, nobody did that so far. And as said before, nobody proposed an alternative that would help with the initial goals.

Keep in mind that the whole system is 

 

I don't care if nobody works on what I've suggested. I'm saying that if we were going to work on it, we're better of starting with a smaller scope and at a lower level abstraction and building upwards.

If "we" were going to work, they would need a basis on which to discuss upon and build over. That is a proposal.

 

I think this proposal will do more harm than good, fragment compilers/platforms more instead of bringing them together, and waste unnecessary cycles that could be productively spent working on other initiatives.

Noted. Though I don't see the relationship with implementation fragementation and this proposal. Also I don't know what you mean by "bringing them together"?

What is wasted is spending a lot of time criticizing an effort without poinging or providing an actual alternative.

Although some of your points are interesting, they still need to be exposed and rely on specific points for us and the committee (we are not all in the committee) to work with.

A. Joël Lamotte

 

[Klaim - Joël Lamotte]

On 23 February 2018 at 23:23, Jeremy Ong <jer...@plexchat.com> wrote:

The goal as stated by the proposal is as follows: "The audience for this technology consists of developers who need to render or display 2D graphics, regardless of what type (games or other)."

I am writing to express a professional opinion that this proposal and implementation will not service the stated goals. It is widely unsuitable for games, will be a constant thorn in the side of the standards committee, and will need to co-evolve with other existing open standards (OpenGL, Vulkan) as hardware changes are made.

Sorry, I totally forgot to ask if you already read this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0669r0.pdf

Most of the point to try to address are already rebutted there.

Maybe if you decide to actually write a proposal (to not continue with the current one), you would set it up as an answer to P0669.

Joël Lamotte

 

[Ville Voutilainen]

On 24 February 2018 at 06:41, Jeremy Ong <jer...@plexchat.com> wrote:
> I don't care if nobody works on what I've suggested. I'm saying that if we
> were going to work on it, we're better of starting with a smaller scope and
> at a lower level abstraction and building upwards. I think this proposal
> will do more harm than good, fragment compilers/platforms more instead of
> bringing them together, and waste unnecessary cycles that could be
> productively spent working on other initiatives.

So you think, but _why_? What harm does the graphics proposal do? What
is this claim of
fragmentation based on? What does it have to do with compilers?

[Olivier Giroux]

That paper mostly lays out « why do graphics »; I doubt if anyone would argue against it on that level.

I’ve given NVIDIA’s feedback F2F to the authors at every few meetings, starting from the very first one. It hasn’t been addressed, so NVIDIA’s position will be No on this proposal. To be most clear, it might have been completely acceptable as a proposal 20 years ago, but the longevity of its abstractions are all but spent now, before it will ever ship.

From the start we have advised to layer around hosting a web browser’s engine and whisper higher-level HTML5/SVG constructs to it, with DPI/format agnosticism by default. Every vendor has massive investments in this; it would serve the community much more to create modern-feeling « apps » than present Win95/X11 constructs. I’ll note that JF brought this up as a question in his reply to the steering group’s paper.

Finally, I don’t know what our position would be on a 3D proposal. The bar would be high, that’s all I know.

Sincerely,

Olivier

--

You received this message because you are subscribed to the Google Groups "SG13 - HMI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sg13+uns...@isocpp.org.
To post to this group, send email to sg...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/sg13/.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/sg13/CAOU91ONmU8ruRv%2BK_MGRQRgi13j9XTHr_OFwZq1j8-HA%2Bgi77Q%40mail.gmail.com.

[Thiago Macieira]

On Saturday, 24 February 2018 12:31:16 PST Olivier Giroux wrote:
> From the start we have advised to layer around hosting a web browser’s
> engine and whisper higher-level HTML5/SVG constructs to it, with DPI/format
> agnosticism by default. Every vendor has massive investments in this; it
> would serve the community much more to create modern-feeling « apps » than
> present Win95/X11 constructs. I’ll note that JF brought this up as a
> question in his reply to the steering group’s paper.
>
> Finally, I don’t know what our position would be on a 3D proposal. The bar
> would be high, that’s all I know.

I don't think either of the two options would fit all cases. Yes, HTML5/SVG-
like declarative constructs have their place and definitely DPI-independence.
I assume you were talking about writing in C++ the engine that takes that
input, as opposed to writing declarative in C++. 3D will likely take up
another niche and could but will not necessarily overlap HTML5 engine.

There's another niche which is that of constrained devices that only need 2D.
Just think of all the IoT devices that may pop up in the next 5 years and will
have displays (the vast majority of IoT won't). This is what I think the
current papers most attempt to address. So to be honest, I don't think those
papers are wrong, they are just insufficient. That's not a reason to stop
them. But we need to understand the limitations and use-cases.

Then there's of course all the new technologies, like AR/VR/MR, CV, and input
sensors that go with it.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Olivier Giroux]

On Feb 24, 2018, at 1:43 PM, Thiago Macieira <thi...@macieira.org> wrote:

On Saturday, 24 February 2018 12:31:16 PST Olivier Giroux wrote:

From the start we have advised to layer around hosting a web browser’s

engine and whisper higher-level HTML5/SVG constructs to it, with DPI/format

agnosticism by default. Every vendor has massive investments in this; it

would serve the community much more to create modern-feeling « apps » than

present Win95/X11 constructs. I’ll note that JF brought this up as a

question in his reply to the steering group’s paper.

Finally, I don’t know what our position would be on a 3D proposal. The bar

would be high, that’s all I know.

I don't think either of the two options would fit all cases.

Right, we will inevitably please some but not all constituencies, whatever we do.

Yes, HTML5/SVG-

like declarative constructs have their place and definitely DPI-independence.

I assume you were talking about writing in C++ the engine that takes that

input, as opposed to writing declarative in C++.

I meant to make an analogy to using a browser’s engine, and not to writing one. 

The declarative form would be an IR here,  perhaps exposed for serialization.

3D will likely take up

another niche and could but will not necessarily overlap HTML5 engine.

To be clear, I would not propose 3D in C++.

There's another niche which is that of constrained devices that only need 2D.

Just think of all the IoT devices that may pop up in the next 5 years and will

have displays (the vast majority of IoT won't). This is what I think the

current papers most attempt to address.

IIUC, you are defending the current proposal based on a speculative future-want, against the fairly established practice of using browser apps to interface with IoT devices today (to say nothing of everything else they are used for, which is arguably more important overall).

So to be honest, I don't think those

papers are wrong, they are just insufficient. That's not a reason to stop

them. But we need to understand the limitations and use-cases.

Yeah but we are saying something with our choices. I think the above is an odd thing for WG21 to want to say.

Now... I don’t have a great answer to « but where’s your paper? ». I hoped it would evolve as people interacted. I could never get any 2D graphics experts to sign up for the huge amount of work it would take to write a counter-proposal.

Basically a large-enough proposal is very difficult to influence. It can sail for a long time without contest.

Then there's of course all the new technologies, like AR/VR/MR, CV, and input

sensors that go with it.

--

Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org

 Software Architect - Intel Open Source Technology Center

--

You received this message because you are subscribed to the Google Groups "SG13 - HMI" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sg13+uns...@isocpp.org.

To post to this group, send email to sg...@isocpp.org.

Visit this group at https://groups.google.com/a/isocpp.org/group/sg13/.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/sg13/12617695.pnEiOrK3G8%40tjmaciei-mobl1.

[Olivier Giroux]

One other thing: the OP of this thread has a different opinion from what I wrote, but I find a lot of merit in it too.

Cheers,

Olivier

> On Feb 24, 2018, at 1:43 PM, Thiago Macieira <thi...@macieira.org> wrote:
>

> --
> You received this message because you are subscribed to the Google Groups "SG13 - HMI" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sg13+uns...@isocpp.org.
> To post to this group, send email to sg...@isocpp.org.
> Visit this group at https://groups.google.com/a/isocpp.org/group/sg13/.

> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/sg13/12617695.pnEiOrK3G8%40tjmaciei-mobl1.

[Thiago Macieira]

On Saturday, 24 February 2018 16:54:45 PST Olivier Giroux wrote:
> > Yes, HTML5/SVG-
> > like declarative constructs have their place and definitely
> > DPI-independence. I assume you were talking about writing in C++ the
> > engine that takes that input, as opposed to writing declarative in C++.
>
> I meant to make an analogy to using a browser’s engine, and not to writing
> one.

In this case, it would be the same thing. The difference would only be the
HTML5 parser, which is not SG13 material. The layering and tiling model would
be the same.

> The declarative form would be an IR here, perhaps exposed for
> serialization.

Perhaps not at all.

> > 3D will likely take up
> > another niche and could but will not necessarily overlap HTML5 engine.
>
> To be clear, I would not propose 3D in C++.

I would. 3D is a valid graphical output, which means it would need to be taken
into account. Even if that account is "use this Vulkan C++ wrapper API, which
our display-access API is compatible with".

> > There's another niche which is that of constrained devices that only need
> > 2D. Just think of all the IoT devices that may pop up in the next 5 years
> > and will have displays (the vast majority of IoT won't). This is what I
> > think the current papers most attempt to address.
>
> IIUC, you are defending the current proposal based on a speculative
> future-want, against the fairly established practice of using browser apps
> to interface with IoT devices today (to say nothing of everything else they
> are used for, which is arguably more important overall).

This is not speculative and I'm not defending the current proposal. I don't
like it and I think it is a good use of our resources, not with all the APIs
that already exist. But it is the simplest form possible and it does have a
concrete and current use-case: there are devices with displays and they will
continue to exist, with more and more complex displays. So please don't
dismiss them out of hand.

> Now... I don’t have a great answer to « but where’s your paper? ». I hoped
> it would evolve as people interacted. I could never get any 2D graphics
> experts to sign up for the huge amount of work it would take to write a
> counter-proposal.

I understand you. Those 2D APIs designed in the late 1980s and early 1990s
have changed and mutated considerably in the last 30 years. They are now
hugely complex APIs and capturing them into C++ is a herculean task.

IMO, I don't think we need any of those APIs. But if C++ is going to have one
or more of them, I'm going to do what I can to make sure they are proper and
correct.

[David Ludwig]

What about, potentially:

1. simplifying the proposal a bit in terms of allowed drawing primitives.  I.e. do less, but still allow for some amount of drawing
2. increasing the amount of code, and specification, to allow for processing of user-input.  There does not seem to be a lack of libraries, and patterns, that get used to abstract both input, and output, on various platforms.  LibSDL ( https://libsdl.org ), SFML ( https://sfml-dev.org ), and GLUT ( https://www.opengl.org/resources/libraries/glut/ ) all come to mind, here.

-- David Ludwig

[frank...@gmail.com]

在 2018年2月24日星期六 UTC+8上午8:06:15，Nevin Liber写道：

On Fri, Feb 23, 2018 at 4:23 PM, Jeremy Ong <jer...@plexchat.com> wrote:

Conclusion:

Note:  I have no stake in this. 

None of the above is a proposal.  Where are the papers?  Who is committing to champion them?  Has anybody implemented it?  Etc., etc.

SD-4: WG21 Practices and Procedures: "Delay vs. bird in the hand. We cannot act on ideas without papers, and we do not significantly delay progress on concrete proposals in order to wait for alternative proposals we might get in the future."

P0267, or in its previous incarnation, n4073, has been in progress for almost four years.  Counterproposals are welcome, but they have to be more than emails of wish lists of work you are hoping people will go out and volunteer to do.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

It seems you have already gone too far. I have no idea why we need proposals to make someone learn about the fact that "UI is simply different from graphics" or "user input has nothing to do with graphics". Aren't they common sense?

(And one more thing: graphics is not a proper subset of HMI.)

[benjami...@gmail.com]

Thanks for articulating your concerns Jeremy. I think many from the games industry (myself included) would agree with these points.