4 ms·

I am little sceptical and also curious about the Graphics library. Is this meant as a building block for more advanced graphics? Or do you still need to use thi

I am little sceptical and also curious about the Graphics library. Is this meant as a building block for more advanced graphics? Or do you still need to use things like DirectX if you need speed and features?

kllrnohj 8y ago
In terms of the proposal itself it appears to be like an SDL type of thing. It has a basic way to create an output surface and then draw on it. Implementations on Windows may opt to do that with Direct2D. But... it gets a lot of stuff really wrong. Like why does outputsurface have an "fps" argument on the constructor? What on earth is io2d::refresh_style::as_fast_as_possible supposed to mean? That doesn't really map to anything sane. UIs certainly don't behave like that at all, they only redraw on-demand. Even for a game which does refresh "as fast as possible" it still does that with its own game loop which will involve more than drawing, and often pipelined anyway. Why does rgba_color, even though it's 4 floats, only have a valid range from 0.0 to 1.0 with no mention of color space? It seems like it's supposed to be linear, but in that case it should be linear extended sRGB, which has a valid range of -0.5 to 7.5. Or like you can query for display_dimensions, but which display? Adding this to a standard would definitely be a huge mistake. It may make a useful beginners library for just quickly getting up to doodling on the screen, but that's sort of it. You'd never build an actual shipping product off of this proposal.
- raphlinus 8y ago
  The dirty secret is that it's basically Cairo, a 1990's graphics API, with modern C++ syntax. So all of the work that's happened since then, including HDR color spaces, precise control of swapchain present, dynamic multimonitor support, doesn't exist. I also got a chuckle out of chapter 10, text (basically TBD, like that's not one of the biggest of all possible cans of worms). In fairness, piet is currently missing the fancy stuff too. But I'm hopeful we'll get there, in part because we can afford to break compatibility. (Going deep into the weeds, presentation doesn't belong at the piet level, but, in my stack, at the druid-shell level. I'm working on this, using quantitative measurements of latency and power dissipation. But it's all evidence that this stuff is quite hard, and Titus is absolutely right that putting it in to a language standard is folly)
- btmorex 8y ago
  I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true.
  - kllrnohj 8y ago
    > I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. That'd be a reasonable theory except it's not how any of this works anymore. Unless you are exclusive fullscreen it's not possible to get tearing on any modern compositor. Window's DWM, Android's SurfaceFlinger, Linux's Wayland, etc... on all of those you're drawing to an offscreen surface, and when you flip it doesn't go directly to the display it goes to the compositor. You're basically always vsync'd by the compositor. So for a windowed application what you really want is more like Android's Choreographer, or JavaScript's requestAnimationFrame - a callback that just says "hey if you want you could redraw now" for rate limiting purposes more than anything else. And even if you are exclusive fullscreen there's things like adaptive vsync or even just choosing an alternate refresh rate. > Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true. requestAnimationFrame is simply a callback and entirely optional. That'd be backpressure control more than anything else, and you'd still have things like input intermixed with it. Also C++ has threads, so discussing games or loops in JavaScript vs. C++ doesn't really apply in the same ways.
- Reelin 8y ago
  I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_color float values being on [0.0, 1.0] this is super standard in my experience. I would expect any well designed API to map [0.0, 1.0] to pixel values on [0, 255] unless otherwise clearly noted. Color spaces other than raw pixel values I would expect to be indicated by the name. That's consistent with at least OpenGL and Java's AWT, but I think also DirectX and most other APIs.
  - kllrnohj 8y ago
    Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3. OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits). So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.
    - Reelin 8y ago
      Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested. > Most APIs that do [0, 255] are assuming sRGB I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user. > OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats. > This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.
roel_v 8y ago
Someone motivated could build an implementation that uses Direct2D underneath. I think MS has one already. There are provisions in the proposal to expose handles to the underlying graphics systems, for example if you want to render text with DirectWrite (or Pango/Harfbuzz if you're using a Cairo-based implementation). Of course without the appropriate ifdefs this would make your code non-portable at that point. But yeah, as much as I would love to have an out of the box cross platform (2d) graphics library, I worry that by standardizing it, it'll be susceptible to being left behind very soon. Not even mentioning that there is so much stuff 'missing' in the current proposal - like what other color spaces? Image formats? I'd much rather have a graphics library in Boost that can evolve over time, and for people to stop complaining about / shitting on Boost; and maybe a way to have Boost packages work with a package manager, in a way so that you can pick and choose the components you need.
- maxxxxx 8y ago
  After reading other responses I agree that the Graphics library should be done by somebody like Boost. It makes no sense to have it in the standard,

kllrnohj 8y ago

In terms of the proposal itself it appears to be like an SDL type of thing. It has a basic way to create an output surface and then draw on it. Implementations on Windows may opt to do that with Direct2D. But... it gets a lot of stuff really wrong. Like why does outputsurface have an "fps" argument on the constructor? What on earth is io2d::refresh_style::as_fast_as_possible supposed to mean? That doesn't really map to anything sane. UIs certainly don't behave like that at all, they only redraw on-demand. Even for a game which does refresh "as fast as possible" it still does that with its own game loop which will involve more than drawing, and often pipelined anyway. Why does rgba_color, even though it's 4 floats, only have a valid range from 0.0 to 1.0 with no mention of color space? It seems like it's supposed to be linear, but in that case it should be linear extended sRGB, which has a valid range of -0.5 to 7.5. Or like you can query for display_dimensions, but which display? Adding this to a standard would definitely be a huge mistake. It may make a useful beginners library for just quickly getting up to doodling on the screen, but that's sort of it. You'd never build an actual shipping product off of this proposal.

raphlinus 8y ago
The dirty secret is that it's basically Cairo, a 1990's graphics API, with modern C++ syntax. So all of the work that's happened since then, including HDR color spaces, precise control of swapchain present, dynamic multimonitor support, doesn't exist. I also got a chuckle out of chapter 10, text (basically TBD, like that's not one of the biggest of all possible cans of worms). In fairness, piet is currently missing the fancy stuff too. But I'm hopeful we'll get there, in part because we can afford to break compatibility. (Going deep into the weeds, presentation doesn't belong at the piet level, but, in my stack, at the druid-shell level. I'm working on this, using quantitative measurements of latency and power dissipation. But it's all evidence that this stuff is quite hard, and Titus is absolutely right that putting it in to a language standard is folly)
btmorex 8y ago
I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true.
- kllrnohj 8y ago
  > I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. That'd be a reasonable theory except it's not how any of this works anymore. Unless you are exclusive fullscreen it's not possible to get tearing on any modern compositor. Window's DWM, Android's SurfaceFlinger, Linux's Wayland, etc... on all of those you're drawing to an offscreen surface, and when you flip it doesn't go directly to the display it goes to the compositor. You're basically always vsync'd by the compositor. So for a windowed application what you really want is more like Android's Choreographer, or JavaScript's requestAnimationFrame - a callback that just says "hey if you want you could redraw now" for rate limiting purposes more than anything else. And even if you are exclusive fullscreen there's things like adaptive vsync or even just choosing an alternate refresh rate. > Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true. requestAnimationFrame is simply a callback and entirely optional. That'd be backpressure control more than anything else, and you'd still have things like input intermixed with it. Also C++ has threads, so discussing games or loops in JavaScript vs. C++ doesn't really apply in the same ways.
Reelin 8y ago
I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_color float values being on [0.0, 1.0] this is super standard in my experience. I would expect any well designed API to map [0.0, 1.0] to pixel values on [0, 255] unless otherwise clearly noted. Color spaces other than raw pixel values I would expect to be indicated by the name. That's consistent with at least OpenGL and Java's AWT, but I think also DirectX and most other APIs.
- kllrnohj 8y ago
  Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3. OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits). So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.
  - Reelin 8y ago
    Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested. > Most APIs that do [0, 255] are assuming sRGB I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user. > OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats. > This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.

roel_v 8y ago

Someone motivated could build an implementation that uses Direct2D underneath. I think MS has one already. There are provisions in the proposal to expose handles to the underlying graphics systems, for example if you want to render text with DirectWrite (or Pango/Harfbuzz if you're using a Cairo-based implementation). Of course without the appropriate ifdefs this would make your code non-portable at that point. But yeah, as much as I would love to have an out of the box cross platform (2d) graphics library, I worry that by standardizing it, it'll be susceptible to being left behind very soon. Not even mentioning that there is so much stuff 'missing' in the current proposal - like what other color spaces? Image formats? I'd much rather have a graphics library in Boost that can evolve over time, and for people to stop complaining about / shitting on Boost; and maybe a way to have Boost packages work with a package manager, in a way so that you can pick and choose the components you need.

maxxxxx 8y ago
After reading other responses I agree that the Graphics library should be done by somebody like Boost. It makes no sense to have it in the standard,