I stumbled upon this issue in the tracker where @Geoff_Perlman suggests OpenGL should be removed from the framework since Apple have deprecated it.
Can anyone provide some support on this ticket to either NOT do this or to at least (finally) provide a replacement canvas control that actually uses the GPU for drawing instead of the CPU?
This is an issue I’ve been asking Xojo for years with no effect. Every time I raise it people pile in saying it’s a good idea (e.g use Metal or Vulkan) but nothing changes. It’s really frustrating.
6 Likes
Yes, this side needs an update.
I often get emails from non-coders asking why my app isn’t making use of their several-hundred dollar-graphics card.
tbh, it’s uncomfortable.
2 Likes
There’s an open source 2D graphics library called “Skia” from Google for all platforms that Xojo supports. Maybe @Christian_Schmitz or @Björn_Eiríksson could make a plugin to use this in a Xojo canvas.
http://skia.org
3 Likes
Yes I also use Flutter and they have a canvas control similar to Xojo’s that lets you draw images and primitives. It’s all done by the GPU and is very fast.
I don’t think it’s acceptable that the GPU is completely unused in Xojo. We shouldn’t have to use complex declares or calls into Metal, etc to draw pictures and primitives on a canvas with Xojo. That’s not what I pay for. I want a simple to use API.
I would love for @Christian_Schmitz or @Björn_Eiríksson to help but it would need to have an API similar to the existing canvas.
3 Likes
Well are we talking about 3d or 2d context?
Xojo switched to Direct2d (on Windows) in 2016. All drawing operations are hardware accelerated.
I don’t know if it’s accelerated on mac.
For 3d there is really nothing. But I don’t think Skia is the right choice for 3d rendering.
I’m not interested in 3D, just 2D.
On the Mac, I can draw pictures and primitives on the native Xojo Canvas and using Activity Monitor my GPU always stays at 0.0%.
As an example, download and run my ImpulseEngine physics demo and you’ll see in Activity Monitor that the CPU gets hammered and the GPU is not used.
1 Like
If you are interested this please give a thumbs up on the issue tracker:
https://tracker.xojo.com/xojoinc/xojo/-/issues/69412
Eventually, OpenGL will be officially retired by all Operating Systems for 3D drawing. If you have experience with OpenGL, then moving to Vulkan is a lower learning curve. I would not suggest learning Vulkan as a beginner, since the learning-curve is very high.
OpenGL can be run on Linux, Windows, and Mac OS. Vulkan can run on Linux, Android, Unix, Windows, Nintendo, BSD, Mac OS, iOS, and many other operating systems. Eventually all 3D acceleration will be Vulkan.
My personal view of a simple triangle example for code differences between OpenGL and Vulkan are that Open GL can make a Hello World Triangle in under 100 lines of code. The same Hello World triangle in Vulkan requires about 1000 lines of code. Most of the extra code in Vulkan is with initialization - which is where additional performance is achieved.
Yes, Xojo should have some form of updated 3D graphics ability. I wrote the Xojo OpenGL book (Program OpenGL Core 32-bit with Xojo on Windows and OSX) and the graphics work, albeit there are many OpenGL supporting libraries which should be added.
But incredibly slow!!!
I haven’t been able to upgrade my Xojo Windows install past 2015 because of this.
(and trust me… I REAALLLLY want to… I have a licence, I want 64bit, but…)
The new graphics system is hopeless for me.
2 Likes
I’m rather surprised to hear that on the Mac, Xojo’s drawing functions somehow avoid using the GPU. I’m no expert but I couldn’t find any functionality in CoreGraphics that lets you choose what rendering system is used (CPU or GPU).
It would be best to have a Xojo engineer weigh in… but in the meantime, several of you have mentioned specific examples in your code where the CPU seems to be doing all the work. Are you doing your drawing in the Paint event of a window or window control? When you draw, are you drawing into an off-screen buffer picture that is then used in the Paint event?
I ask because deep in the recesses of my memory lies this notion that once upon a time drawing to an off-screen buffer did not use the GPU on the Mac.
See my open source example here:
You can see the drawing I’m doing in the Paint event of the Canvas.
When you draw, are you drawing into an off-screen buffer picture that is then used in the Paint event?
I’ve tried both methods.
I dont believe that doing it all in the paint event could be faster than just chucking a ready-drawn picture at the canvas in the paint event.
And (on windows), surely a bitblt operation would be the number 1 thing they would optimise?
If you already have a picture ready to go, then painting it is probably best. What is probably NOT best is to recreate that picture every time you respond to the Paint event.
A physics engine / game engine needs to invalidate (ie paint) the canvas 30-60 times per second. Each frame you need to re-render visible bodies. The performance is no different if I draw to a picture then blit to the canvas in the paint event or draw to the graphic context directly in the paint event. In any case, the GPU is never utilised.
1 Like
I don’t want to get sucked into performance optimisation of that code in the canvas in ImpulseEngine. That’s for demo purposes only.
My concern is no matter what you throw at the canvas, it doesn’t utilise the GPU.
If I run similar code in other tools (eg Flutter) I can clearly see the GPU being accessed in Activity Monitor.
Same here.
I want ‘what I chuck at the canvas’ to be handled by the best thing in the machine to handle graphics.
If you own a Ferrari, why would you cycle across country?
2 Likes
Typically, if you own a Ferrari, you should own two, or a bicycle, so that you can still get around after you’ve wrapped one around a light post. Oh, wait, that’s a Mustang 
1 Like
In all fairness, I would blame Apple more than I blame Xojo. For the simple fact that Apple could have optimized OpwnGL, they could have adopted Vulcan, they could have even made Metal compatible with DirectX, but they made their own proprietary system, completely ignoring the benefits that OpenGL bought to the platform back in '98.
As for Xojo, I suspect that there’s not enough interest from their current target audience to warrant investment in this area.
If you’re serious about making games, I would suggest looking into Unreal or Unity, even for 2D. These should shield you from platform specifics, and allow you to focus on your game.
Otherwise, you’re focusing on Mac, you can use declares to access CALayers, I hate CALayers, but there is some great power in here for a classic Pokemon adventure game. You could create a framework as the foundation for this kind of game so that it uses CALayers on Mac, and whatever on Windows.
That is correct, UI drawing is performed on the CPU, but it is cached to the GPU. You could create one canvas as the background layer, and use separate canvases for the sprites. This would give you a performance boost on the Mac, heck you could even use actual windows (again with some declares).
2 Likes