Hacker News Reader

Comment by phkahler | Hacker News Reader

The idea of adding a graphics API to a language standard is incredibly misguided. There are plenty of 2D graphics APIs already from SDL to one in QT, GTK, Cairo, Canvas, and then the more proprietary ones. People can not seem to stop creating them.

Perhaps people thought if a GFX API were incorporated into the C++ standard it would replace all the others, but... Can anyone imagine that actually happening? Really?

I'd be happy if languages would adopt Vec2 Vec3 and Vec4 as standard data types - both float and double. I understand there are ways to create these in most any language, I just want them standardized so we can all write code the same way and get the performance of some vector instructions without using intrinsics.

If they can't even standardize the obvious (fixed length) vector types used in graphics (and other things) they really shouldn't try to define a graphics API.

View on HN

Yes. Over 15 years ago I proposed a library for Vec2, Vec3, and Vec4 to the C++ standards committee. It's the one from Graphics Gems, but rewritten as all inline.[1] The C++ standards people wanted more usage of templates.

A few academic projects use that code.

[1] http://www.animats.com/source/index.html

What the C++ (and C) stadards could use is a native type for SIMD vectors. In other words, standardize the GCC vector extensions [0] or some variant thereof.

Just adding a new header-only library for vector arithmetic isn't something that needs to be in the language standard (library), there are lots of options for that already (such as glm[1]).

I've been using vector extensions for my 3d graphics and physics stuff for years now and it works great. There are some pain points, but it already covers most of what I need. As a bonus, it can be used in plain C and you get all the usual math operators (+, -, /, etc) for free. There are minor incompatibilities between GCC and Clang, but nothing a few #ifdefs won't solve.

Here's a quick introduction in a few lines of code:

    typedef float vec4f __attribute__((vector_size(16)));
    vec4f a = { 1, 2, 3, 4 }, b = { 5, 6, 7, 8 };
    vec4f c = a + b;
    vec4f d = (a + b) * c; // with --ffast-math, you will get fused multiply-and-add (MAD)

In my projects, I've always put together an ad-hoc collection of arithmetic routines I need (e.g. dot, cross, matrix product, inverse, etc). A proper, well tested library of basic math operations for SIMD vectors would be very useful but I haven't got the time it takes.

If anyone is interested, some of my math routines are bundled in this github repo [2]. It's incomplete, undocumented, not well tested and there are known issues I haven't gotten around to (e.g. quaternion products give wrong results).

If anyone thinks this is useful and is interested in contributing/collaborating, leave a comment.

[0] https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

[1] https://glm.g-truc.net/0.9.9/index.html

[2] https://github.com/rikusalminen/threedee-simd

This is exactly what I'm talking about. I want these vectors as standard types. First class data types, not part of a library or typedef. The example given in the parent comment is spot on with typical use.

I like that GCC defined their own way to declare these that is independent of x86, ARM, and Altivec intrinsics so your code is portable (so long as you use GCC). Geometrically relevant vectors are common enough to be native types, let's get there.

> so your code is portable (so long as you use GCC)

Or Clang!

There are only minute differences between vector extensions in GCC vs. Clang. Little things like __builtin_shuffle vs. __builtin_shufflevector.

There are some efforts underway to standardize using SIMD but this is really a separate problem to providing a short vector math library suitable for the kind of linear algebra useful for 3D graphics and physics.

Making your vec4f type a SIMD register type is not a good way to make use of SIMD hardware. The best approach is generally an SoA (Struct of Arrays) rather than an AoS (Array of Structs) and the best CPU programming model for that is something like ispc[1].

Nathan Reed has a good summary of why "naïve" SIMD libraries after not the way to go for short vector math: http://www.reedbeta.com/blog/on-vector-math-libraries/#how-t...

On some platforms alignment issues become a big problem for naïve vector math libraries too, though this is less of an issue on current generation x64 hardware.

[1] https://ispc.github.io/ispc.html

> There are plenty of 2D graphics APIs already from SDL

SDL2 doesn't have a 2D graphics API in the traditional sense. It has a basic bitmap software blitter designed for debugging and bootstrapping. SDL2's main forte is just a being a cross-platform wrapper around the HW-accelerated APIs like OpenGL and Direct3D.

> to one in QT, GTK, Cairo

While Qt does indeed have QPainter, it is switching away from QPainter towards OpenGL with QtQuick. GTK+ uses Cairo (with plans to switch to OpenGL/Vulkan as well). So so far, our list is down from 4 to 2.

> and then the more proprietary ones

I'd list it as: GDI+ (Microsoft), Quartz 2D / CoreImage (Apple), Skia (Google) and Cairo (X.org). HTML5's <canvas> API is taken from Quartz but is often backed by the others.

So there are not that many choices for a modern 2D vector graphics library. My main issue with the 2D proposal is that hardware acceleration and modern graphics just flat out doesn't work the way the 2D API expects it to. You can be very good at pretending, but at some point you'll have to grow up, put on your big boy clothes, and use learn how GPUs work. Hence why there's the heavy migration away from the others. Direct2D has a good example here of a good API, even if the implementation is a bit wacky. Pathfinder 2 is similar.

> SDL2 doesn't have a 2D graphics API in the traditional sense. It has a basic bitmap software blitter designed for debugging and bootstrapping.

This is actually incorrect. The SDL Render API does use GPU acceleration.

Indeed it does, and you can use it to draw accelerated scaled and rotated images, lines, and rectangles. There are even a few blending modes available. It's a nice foundation for simple cross-platform 2D graphics, it's come a long way since SDL1.

There's also old SDL's rival, Allegro 5, which also provides nice GPU accelerated graphics API.

SDL2's render API can use GPU acceleration, however its feature set is rather limited. This is plenty for many, however is incomplete for others. I've heard its feature set be referred to as 'SNES-level graphics', or something to that effect, from at least one SDL-internals dev, something which I'd also echo.

I'd like to see a reasonably-standard C++ API specification for at least a few graphics-related things (and perhaps more over time), but am not sure if writing a graphics API with the sole goal of eliminating all other APIs or libraries, would make any sense. The people with whom I've talked to, some of whom have done work on P0267/io2d, don't seem to be explicitly aiming for this either, but perhaps I've missed something.

I'd be happy to see vec2/vec3/vec4 style APIs in the C++ standard, too. P0267/io2d does have some support for this, although I think it could certainly stand to get some love + attention!

From what I heard in some c++ podcasts the goal isn't creating ultimate graphic API, it doesn't need to be usable by proffesionals. It is aimed mostly at beginners and people teaching C++. Having single interface for things like Vec2 was also consider. There are hopes it could be make mixing and switching third party graphic libraries easier by having common types.

That sounds a lot more like what they should aim for: Formalizing algebra.

It's probably a far safer bet that algebra won't be changing very often, much less so than any graphics pipeline!

I think they would be wise to think a little beyond beginners though. Algebra does not have to be always complicated, but it definitely needs to be open-ended to extend its usefulness.

The standard has been burned by short-sightedness before.

Before they added std::string, there were plenty of string APIs already. People couldn't seem to stop creating them.

A graphics API won't replace all the custom-made graphic APIs, just as std::string didn't replace all the custom-made string libraries. Nevertheless, it's great to know you have something readily available.

Reply on news.ycombinator.com