4 ms·
So I read the 2D graphics prop, P0267[1] and this summary[2], and it seems to suffer from most of the problems that caused, e.g., HTML5 Canvas to be superseded
by arandr0x 8y ago
So I read the 2D graphics prop, P0267[1] and this summary[2], and it seems to suffer from most of the problems that caused, e.g., HTML5 Canvas to be superseded by WebGL whenever it became practical to do so in most browsers. (And Canvas had the solid advantage of having no competitors. C++ has Qt and Cairo and boost and about five hundred game engines.)
2D matrices with no 3D do not meet the requirements for most complex applications. (At least there are inversions though). Even in 2D applications, usually the world ends up being, de facto, a 3D one (they are "2D with layers", so that the world does have z coordinates). Those applications may only need 2D rendering, but they do use (limited) 3D linear algebra.
I also think there probably should be oriented bounding boxes, even for 2D. "Simple" APIs that only provide axis aligned bounding boxes, which yes, is almost all of them, cause beginner programmers tons of headaches as they have to figure out linear algebra to do such things as "tell me if the closest box around this rotated object intersects the closest box around this other rotated object".
The emphasis on vector graphics seem strange. Even in platforms like Android, we haven't seen vector graphics come to the forefront, instead, the approach used for UI graphics scaling is providing raster graphics at different resolutions. Vector graphics are not, in fact, more efficient for the majority of applications, and providing essentially zero read/write capability for common vector formats doesn't help.
It seems to be intended to be a teaching API. Undergrad courses don't use C++ as much as they did when, well, I was in undergrad, but those that do teach graphics with OpenGL (not even Cairo or Qt). Why? Well, 2D-only non-hardware accelerated graphics are not, in fact, hugely useful or relevant to the vast majority of C++ programmers. Though I am primarily a C++ programmer, I write UIs in C# or Java (yes, I know). The proposed spec, anyway, does not even have a "create window" API, making it pretty bad as a basis for a UI toolkit (presumably you still have to obtain the window handle through platform-dependent means). The reason I don't write charts in C++ is not actually the lack of 2d APIs, Qt is accessible enough, it's the lack of good, easy data input facilities compared to languages like Python (or well, JavaScript...). When reading XML or CSV requires a library no one is going to use your language for charting.
And as a last point that I admit is more of an aesthetic issue, what is up with preceding all data types with "basic_"? They're basic in Qt and HTML5 Canvas but none of those actually call it a "basic_circle" anyway. This is going to turn autocomplete into a terrible pain as well as add five characters to every line for pretty much no reason. Just call it circle, we won't mind.
[1]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0267r7.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p026...
[2]http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0669r0.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0669r0....
- deleted 8y ago[deleted]