-
Hi, I've been looking into Slint for the last few days and love it so far. I've been looking at the opengl_texture and opengl_underlay examples to understand how to render with raw OpenGL (via glow) alongside Slint, but one issue is that the get_proc_address function I get from GraphicsAPI::NativeOpenGL loads a 3.2 version of OpenGL. Is there any way to request that the context be created with a higher version, so that more up-to-date OpenGL/GLSL functionality can be used? I have looked into the source code for the backends to try and understand if something like this is possible, but the code is quite complex and I'm still not entirely sure how they work, so hopefully this isn't a silly question or impossible ask :) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
That's a very good question and I'm not entirely sure of the correct answer either ;). We request a context that supports GLES 2.0, using with_context_api(). I think I've seen this sometimes resulting in contexts being created that are actually GLES 3.0 for example, but AFAIK that's fine as long as for example the renderer only uses GLES 2.0 features. I've had a situation once where the use of a vertex array object with a slint underlay clashed because the underlying renderer didn't use VAOs and expected the pristine 2.0 state, but saving/restoring it properly fixed it. What functionality specifically are you looking for, btw? More generally, I think these kind of specific needs might be best covered in a way where the application can compose the setup, by picking for example the winit backend (we'd like to make that public), along with a renderer, and then use renderer-specific API for more fine-grained graphics setup. For example for the FemtoVG renderer you could set up the GL context yourself and just provide the OpenGLInterface. |
Beta Was this translation helpful? Give feedback.
That's a very good question and I'm not entirely sure of the correct answer either ;). We request a context that supports GLES 2.0, using with_context_api(). I think I've seen this sometimes resulting in contexts being created that are actually GLES 3.0 for example, but AFAIK that's fine as long as for example the renderer only uses GLES 2.0 features. I've had a situation once where the use of a vertex array object with a slint underlay clashed because the underlying renderer didn't use VAOs and expected the pristine 2.0 state, but saving/restoring it properly fixed it.
What functionality specifically are you looking for, btw?
More generally, I think these kind of specific needs might be …