5 ms·

What is REAPER doing that it needs to fling so many bitmaps to the screen at once? Wouldn't that be done more efficiently with GPU texture wrangling?

TD-Linux 10y ago
Probably things like spectrograms, waveforms, etc. For a lot of effects it doesn't really pay to GPU accelerate their drawing - in this case looks like REAPER is using custom drawing code into an image, but the compositing these image widgets together with native Apple drawing functions onto the final window plane. Doing the final compositing step with the GPU and shader color conversion is one option. Two other options I'm surprised weren't mentioned were drawing the image widgets in the final colorspace to avoid the conversion step, and specifically requesting an 8-bit sRGB window for system compositor-side conversion (I'm not sure if OS X supports the latter).
deleted 10y ago
[deleted]
louhike 10y ago
Maybe to display the VSTs. The more recent ones can be quite complex.
- illicium 10y ago
  VSTs draw their own graphics. They're basically separate applications that have an audio/MIDI pipe to the host.
- astrodust 10y ago
  Sure, but if you're doing intensive graphics of any sort you really need to use OpenGL for compositing. Doing it at the OS layer is really inefficient.
justinfrankel 10y ago
Rendering the arrange view, which can change drastically in response to user edits. We've tested using OpenGL to update, but as the texture needs to get uploaded each frame it's only marginally faster, and uses significantly more resources.
zbuf 10y ago
I can't comment on Reaper specifically, but to those who haven't used audio applications they often have more in common with a game than a regular desktop application. The software is often generating live displays in response to interactive or live input (ie. the audio being synthesised, processed or played); everything from fancy spectrograms to meters showing levels. GPU features like texturing works great if you can upload everything you need in advance from the CPU, and then re-use it again and again on the GPU side. However, in the case of these sorts of applications that input is one or many audio streams which are constantly changing. I'd bet you /could/ implement more of the processing on the GPU itself. But audio apps like this are often multi platform and based on existing codebases or plugins. Pixel-pushing to the screen seems rather boring, but it typically throws up fewer bugs; I'd say it makes more commercial sense to spend time working on audio features than debugging GPU issues on a wide range of platforms.
- astrodust 10y ago
  I'm not saying it's easy to write shader code for all of these things to offload the bulk of the drawing work to the GPU, but it would provide a huge boost to performance. OpenGL makes for fairly portable code, especially if you're doing something extremely narrow like rendering on a 2D texture canvas. It's only when you start to use exotic OpenGL features that you quickly get into trouble.

TD-Linux 10y ago

Probably things like spectrograms, waveforms, etc. For a lot of effects it doesn't really pay to GPU accelerate their drawing - in this case looks like REAPER is using custom drawing code into an image, but the compositing these image widgets together with native Apple drawing functions onto the final window plane. Doing the final compositing step with the GPU and shader color conversion is one option. Two other options I'm surprised weren't mentioned were drawing the image widgets in the final colorspace to avoid the conversion step, and specifically requesting an 8-bit sRGB window for system compositor-side conversion (I'm not sure if OS X supports the latter).

deleted 10y ago

[deleted]

louhike 10y ago

Maybe to display the VSTs. The more recent ones can be quite complex.

illicium 10y ago
VSTs draw their own graphics. They're basically separate applications that have an audio/MIDI pipe to the host.
astrodust 10y ago
Sure, but if you're doing intensive graphics of any sort you really need to use OpenGL for compositing. Doing it at the OS layer is really inefficient.

justinfrankel 10y ago

Rendering the arrange view, which can change drastically in response to user edits. We've tested using OpenGL to update, but as the texture needs to get uploaded each frame it's only marginally faster, and uses significantly more resources.

zbuf 10y ago

I can't comment on Reaper specifically, but to those who haven't used audio applications they often have more in common with a game than a regular desktop application. The software is often generating live displays in response to interactive or live input (ie. the audio being synthesised, processed or played); everything from fancy spectrograms to meters showing levels. GPU features like texturing works great if you can upload everything you need in advance from the CPU, and then re-use it again and again on the GPU side. However, in the case of these sorts of applications that input is one or many audio streams which are constantly changing. I'd bet you /could/ implement more of the processing on the GPU itself. But audio apps like this are often multi platform and based on existing codebases or plugins. Pixel-pushing to the screen seems rather boring, but it typically throws up fewer bugs; I'd say it makes more commercial sense to spend time working on audio features than debugging GPU issues on a wide range of platforms.

astrodust 10y ago
I'm not saying it's easy to write shader code for all of these things to offload the bulk of the drawing work to the GPU, but it would provide a huge boost to performance. OpenGL makes for fairly portable code, especially if you're doing something extremely narrow like rendering on a 2D texture canvas. It's only when you start to use exotic OpenGL features that you quickly get into trouble.