GUI Drawing Efficiency

BTW: for anyone reading this (old!) thread who’s interested in graphics performance, I should mention that Tom Poole and I will be doing a workshop session at ADC this year about how to optimise rendering speed, with slightly more up-to-date info than in here!

12 Likes

Metal and Vulkan with a side helping of CUDA?

Would anyone care to elaborate on this? What would those 4 lines of code be?

I’ve never tried any of the GL stuff thinking that it would only be applicable for 3D stuff, but I’m drawing a lot of bitmaps and if it’s faster with GL, that would be fantastic.

probably the

OpenGLContext context;

as a class member of your OpenGLRenderer component
hint:

class MainContentComponent : public Component, public OpenGLRenderer
{
    ....
};

and then in your constructor

    context.setRenderer (this);
    context.attachTo (*this);
    context.setContinuousRepainting (true);

the setComponentRepainting() causes this line in OpenGLContext::renderFrame() to call your component’s paint(Graphics& g) method:

notice that on line 250, that’s where the renderOpenGL() callback happens, and that is also (partly) why the components will always draw on top of the OpenGL viewport.

Thank you! I’ll take a look at this.

Is that line truly needed? It seems only if you want to do 60 fps animations 100% of the time. If you only want to accelerate the occasional update, then it seems a bit wasteful to redraw the entire GUI over and over and over.

You just need to create the context object and call attachTo().
No need to inherit OpenGLRenderer or to call setRenderer or setContinuousRepainting unless you’re doing actual raw GL calls yourself.

2 Likes

I find using this approach really helps the fluidity of my UIs, it’s so easy to use and very effective. I’m really hoping by the time OpenGL is removed from macOS we have an equally good or better way of achieving the same thing with Juce.

2 Likes

OpenGL is going to be removed? Why?

It is apples’ plan for upcoming OSX versions, see this thread:

I’d be very surprised if they actually removed it anytime soon - it would break far too many things.

Just like how they’d never remove the audio jack right?
/s

1 Like

In terms of it being available for users, true it probably will stick around for ages as it would break a lot of existing things, but I can see it being removed from the macOS frameworks after Mojave on a much shorter time frame. Sure we don’t have to use them, but it’s only feasible to resist that kind of pressure for so long as eventually something bites you.

I can’t even update to Mojave cuz my computer is too old, so OpenGL is safe on my computer! :raising_hand_man:

“OpenGL is going to be removed? Why?”

Apple are promoting their newer Graphics API “Metal”. My guess is OpenGl can (and will) be ported to run as a layer on top of Metal, just like OpenGl has been ported to run on top of Microsoft’s native graphics API “DirectX” via “ANGLE”.

That’s not how OpenGL works at all. The GPU driver is what supports OpenGL, and the Win32 APIs (or any native APIs from an OS, like Xlib on Linux) provide ways to interface with it. It has nothing to do with DirectX.

ANGLE is one option for running OpenGL on a platform (winrt) that does not support OpenGL Hardware drivers directly communicating with the GPU. I am suggesting this type of solution may potentially be viable on top of “Metal”, Apple’s Hardware accelerated Rendering API.

“The goal of ANGLE is to allow users of multiple operating systems to seamlessly run WebGL and other OpenGL ES content by translating OpenGL ES API calls to one of the hardware-supported APIs available for that platform. ANGLE currently provides translation from OpenGL ES 2.0 and 3.0 to desktop OpenGL, OpenGL ES, Direct3D 9, and Direct3D 11.”

There’s a paid solution available:

MoltenVK (which translates Vulkan to Metal) is free, however.

1 Like

@jules I’m not sure if this is still relevant, so excuse me for referring to a rather old post of yours, but there is a way to fully control antialiasing on non-antialiased GPU renderer, with relatively little overhead.

If you triangulate the path and upload it to the GPU, you can repeatedly draw the strip using add-composition and proper colour scaling while shifting the geometry in the subpixel range. The buffer will have to be initialised with transparent black and can afterwards be composited with the target buffer. The geometry of the subsample shifts and their relative weight determines the antialiasing method. A simple box super-sampler with 4x4 super samples requires drawing the triangle strip 16 times, which is very fast if done entirely on the GPU. In fact, the entire pipeline can be held within the GPU regime with openGL methods and available shader hooks.

I don’t know if this is compatible with your future plans, but it would be a strategy that is surely entirely agnostic of the rendering backend in use, so it would work with Vulkan and Metal as well.

4 Likes