Edwin Jakobs

To see the `openrndr-nullgl` back-end in action you have a look at the following tests in `openrndr-core`, which are executed with `openrndr-nullgl` on the `testRuntime` class path. https://github.com/openrndr/openrndr/blob/master/openrndr-core/src/test/kotlin/TestDrawContour.kt

Good question. Currently the renderer has no idea in which color space input and/or output reside so it treats all color data as-is. I'd gladly formalize this but I haven't...

> Is it intentional that `.toHSVa().toRGBa()` returns sRGB and `.toLCHUVa().toRGBa()` returns LINEAR? More or less. The HSV transformation is defined as operations in sRGB space. LCHuv works on XYZ primaries...

Yes this would be great! Do you imagine this to be part of orx-palette?

To be considered: (#319)

I edit my issue text usually after I merged in PRs or committed to master. Comments can be used to point out I missed something or provide improved text.

After looking into a bit I suspect it stems from using FFMPEG's older audio decoding functions, and not from OpenAL as claimed prior.

Hi @ylegall it is a fair point and I will look into it. My only concern is in how inlining in general affects the readability of stack traces in case...

This is addressed by https://github.com/openrndr/openrndr/commit/a58312c4ea13f3f4721be171e5f08a9c8e61d383 Will release OPENRNDR 0.3.45-rc.3 later today, which will include that fix

I expect this to work with the gl3 back-end if the DEPTH_STENCIL format is included here: https://github.com/openrndr/openrndr/blob/master/openrndr-draw/src/commonMain/kotlin/org/openrndr/draw/DepthBuffer.kt#L13