3 ms·

The push for a standard 2d api in C++ seems so bizarre to me. There's a place for languages like python that are designed around quickly prototyping things, bu

by oddity 8y ago

The push for a standard 2d api in C++ seems so bizarre to me. There's a place for languages like python that are designed around quickly prototyping things, but this has never really been C++'s domain. Programmers for most of the esoteric, resource constrained platforms where C/C++ really shines don't have much need for a 2d api, or will probably want to write their own. Meanwhile, popular libraries already meet the needs of most of everyone else. Is there a genuine use case for a language-level standard 2d api? To me it seems like it is being pushed as a standard just for the sake of a checkbox, but am I missing something here?

eXpl0it3r 8y ago
One strong argument at the evening session was that not everyone has access to non-standard libraries, which in my opinion is a ridiculous argument. If your work doesn't allow non-standard libraries, then it's time to move on, we really should not feed the companies with the "not invented here"-syndrome. Another argument many people brought up is that it would allow C++ to be more usable as a teaching tool or a few shared their stories of basic graphic programming which eventually landed them in C++. But I really don't see why the standard needs a toy API. If people pick C++ as their learning language, they should be able to learn how to use another library, since that's very much part of learning C++. Besides there are more complicated concepts in C++ than having to follow some dead simple tutorial on getting another library working. And if you go down the teacher route, then it's really no issue setting up a library for those learning. And finally there's the argument of "other languages have it too". Yet, I haven't really seen examples of that. I think .NET has something like that, but then again .NET also has a full API for window creation and tons of other things. Maybe a simple drawing API is a good idea, but first we'd have to add other things to the standard. All in all and seeing the evolution of OpenGL, I simply don't see a reason why the C++ standard needs a simple drawing API right now. There are tons of other things that are way more important and should be added first. And once you get to a standard drawing API, what good is it, when you still have to write custom/platform specific code just to get an actual rendering surface (aka window) on screen? And one final point is, who needs a API that is designed for a software renderer? What year is and who is still running software renderers?
- DLudwig 8y ago
  The authors of the recent, P0267 C++ graphics paper (aka "io2d"; latest revisions getting posted to https://github.com/mikebmcl/io2dts/tree/master/papers https://github.com/mikebmcl/io2dts/tree/master/papers), as far as I've seen (online, mostly), aren't interested in making a "toy" API. Many, if not all of them, want people to be able to do 'real' work with it. They've also seemed willing to accept constructive feedback on it, and are cognizant that there is a good amount more work to be done, if something useful is to be a result! There is, I think, room to work on different C++ features in parallel. A graphics expert isn't necessarily going to want, or be qualified, to lead a charge on all future, non-graphics features. In terms of 'other languages have it too', here's one platform/standard that has it: HTML5. It's Canvas API is pretty widely available, although in practice, perhaps only with sufficiently powerful runtime-processing power. Regarding software renderers, I'd argue that these are still useful, in some use cases. I've worked on some projects whereby a constexpr/compile-time canvas-style implementation would have been useful, I imagine.

by oddity 8y ago

eXpl0it3r 8y ago

One strong argument at the evening session was that not everyone has access to non-standard libraries, which in my opinion is a ridiculous argument. If your work doesn't allow non-standard libraries, then it's time to move on, we really should not feed the companies with the "not invented here"-syndrome. Another argument many people brought up is that it would allow C++ to be more usable as a teaching tool or a few shared their stories of basic graphic programming which eventually landed them in C++. But I really don't see why the standard needs a toy API. If people pick C++ as their learning language, they should be able to learn how to use another library, since that's very much part of learning C++. Besides there are more complicated concepts in C++ than having to follow some dead simple tutorial on getting another library working. And if you go down the teacher route, then it's really no issue setting up a library for those learning. And finally there's the argument of "other languages have it too". Yet, I haven't really seen examples of that. I think .NET has something like that, but then again .NET also has a full API for window creation and tons of other things. Maybe a simple drawing API is a good idea, but first we'd have to add other things to the standard. All in all and seeing the evolution of OpenGL, I simply don't see a reason why the C++ standard needs a simple drawing API right now. There are tons of other things that are way more important and should be added first. And once you get to a standard drawing API, what good is it, when you still have to write custom/platform specific code just to get an actual rendering surface (aka window) on screen? And one final point is, who needs a API that is designed for a software renderer? What year is and who is still running software renderers?

DLudwig 8y ago
The authors of the recent, P0267 C++ graphics paper (aka "io2d"; latest revisions getting posted to https://github.com/mikebmcl/io2dts/tree/master/papers https://github.com/mikebmcl/io2dts/tree/master/papers), as far as I've seen (online, mostly), aren't interested in making a "toy" API. Many, if not all of them, want people to be able to do 'real' work with it. They've also seemed willing to accept constructive feedback on it, and are cognizant that there is a good amount more work to be done, if something useful is to be a result! There is, I think, room to work on different C++ features in parallel. A graphics expert isn't necessarily going to want, or be qualified, to lead a charge on all future, non-graphics features. In terms of 'other languages have it too', here's one platform/standard that has it: HTML5. It's Canvas API is pretty widely available, although in practice, perhaps only with sufficiently powerful runtime-processing power. Regarding software renderers, I'd argue that these are still useful, in some use cases. I've worked on some projects whereby a constexpr/compile-time canvas-style implementation would have been useful, I imagine.