I need faster and better-looking graphics in my apps, and I don’t want to have to rewrite all my code, so I’m considering making an OpenGL Surface subclass that works as a drop-in replacement for the Xojo canvas class.
- Has anyone already done this?
- Are there good reasons not to try this?
- Better ideas?
I’ve read through all the relevant forum posts on OpenGL I could find, so I’m aware that the future of OpenGL is uncertain at best, but I don’t see other viable alternatives at this point.
How is it that OpenGL can create “better looking” graphics?
It might encapsulate functions to make it easier… but if you can draw something in OpenGL, you can draw it using Xojo code too… perhaps not as “easy” (which is relative when talking about OpenGL)
But personally I would not leverage OpenGL as you said… its future is sketchy at best.
I’ve never used OpenGL, but if I understand what I’ve read about it, it’s got all kinds of flashy “eye-candy” type of things built into it.
I would work in 2 stages:
- Drag-drop replacement
- add flashy stuff
By drag-drop replacement, I mean literally I don’t need to change my code, only copy and paste it to the right locations in the new object, which draws lines, rectangles, text, images, etc. the same way the Xojo Canvas does, same properties and events, etc. only it works faster. That’s the idea, anyway. My first concern is speed. I’ve read that OpenGL is faster than the Xojo Canvas. Obviously, I have no personal proof of this.
Dave is correct when he mentions that the quality of graphics on OpenGL and the canvas are the same. The programmer would be responsible for the resolution of the graphics.
The canvas is good for creating graphics - but - the programmer is responsible for the graphics and math in a 3D world, which can get complicated and quite involved on larger projects.
OpenGL has much of the math built-in and can be heavily modified for larger programs.
Speed for both of these would be the same, and the added benefit of OpenGL is that speed has been optimized. All speed Optimization of the canvas will need to happen by the programmer, while OpenGL has some of the speed optimization already.
The issue with speed deals with the timer on windows, which means don’t use a timer for graphics update. A for-next loop in a thread can be used or used the peekmessage API in windows for speed optimization with minimal processsor use.
If you are starting to learn graphics programming then I would suggest you start with a canvas. Once canvas programming has been learned at an intermediate level then OpenGL would be the next logical step.
This is just my personal opinion and others may have better paths to success
More important than using a tank to crack a nut, I would start by making sure my canvas label replacement correctly implements HiDPI for a crisp rendition.
Kinda, but not quite the full extent of a complete canvas, more for displaying 128-Bit bit depth HDR images.
Yup, Apple. They don’t make it easy, haven’t updated their OpenGL library for a long time. It’s a hack job to keep OpenGL working correctly with current macOS versions (and other things such as layer backed-views, which Apple want you to use).
Don’t be surprised if in a few years OpenGL no longer comes installed on a Mac.
It really depends on what you are doing, 99% of the time the Canvas is plenty fast and with the right design it shouldn’t be a problem.
I ONLY use OpenGL in that one program because the image processing that the program displays is done on the GPU,so it’s faster to display content already on the GPU than transfer back to RAM, and then back to GPU.
Thanks to everyone for your input.
I’ve decided not to use OpenGL. My guess is that the Canvas class will improve as Xojo’s underlying APIs are updated to whatever the platforms are adopting (Metal, Vulcan, who knows). I should also work on optimising my existing code. Dragging and dropping a new object wouldn’t do that for me anyway I’ll try to improve my skills using the standard Canvas. Probably it will do what I need.