 Here it's potting open gel in the process. Open gel was used in the process for a few years already. So some famous examples are the open gel transitions and Torsten's open gel canvas. But there's some new support and some changes that make it much easier to use it and to benefit it. So the talk will cover more or less five topics. A short introduction, what is open gel? Then some comments about platforms, libraries that we use around open gel, how to use open gel in the process and finally some features that use it already. And in the end also we look into the future. So what is open gel? Open gel is a cross-platform 3D API. The current version is 4.5. I haven't even looked at anything before. So we have stuck with something 3.0 or even 2.0 something. There are more or less two different approaches. The first open gel version is 0 until 1.5. Use the fixed pipeline approach. That means that more or less the steps that open gel was following for getting from your data to something on the screen was fixed. And starting with open gel 2.0, they introduced a programmable pipeline where each step can be adjusted to the specific needs and you can select some stages that are done and some others that are not in part. So how does it look? That's the structure of open gel 4.3. I didn't find it for open gel 4.5. But it's quite similar. You can forget everything about compute shaders in the process we use open gel for it. But you can also forget most of the other stuff. What we normally use is the vertex shader and the fragment shader. These ones are only available in open gel 4.0 and later. The other stuff is automatically done by the open gel driver. A shader in this sense is more or less a small C-like program that's executed on the CPU instead of the CPU. The vertex shader gets input from you that tells it where each point in your work is. Some additional input like transformations and so on and it generates then the final position on the screen. The fragment shader then colors all the points or pixels on the screen that are in the rear of your triangle. That was the CPU side. But on the CPU side, on your application side you normally work with buffers in modern open gel instead of more or less direct calls. You generate them, you fill them with some data, you bind them and let them pass them to open gel but the GPU side later will release them. You change the state of the open gel state machine. You set the open gel stuff up and put it in the correct state and you select the correct open gel context. The more difficult part of the open gel is the platform. Open gel is a cross-platform so normally you would expect that you could just do the same stuff on all platforms. But open gel starts with an open-gear context so everything below that is not specified and is platform dependent. The open-gear context is more or less an object that tells the GPU, okay, these parts belong together and should be rendered to this window or this abstract platform dependent object in a specific way. But how you get there is specified in I think four different platform or APIs, GLX for the X server, mostly for us at the moment for Linux, WGL for Windows, CGL and NSOpenGL for Mac. So Mac has actually two different APIs. A low-level one that's not based on a window, rendering to a window, you have to do all of that yourself and NSOpenGL which works on a window and uses CGL as back-end. We use all three at the moment for the different platforms that we support. Each year is the one that's used in Brayland I think and on Android. We are not using it yet, we have no support for it yet, but it can be easily added. All of these platform-level stuff is abstracted in the open-gear-context class where we create an abstract, an open-gear-context object that hides all these details from the user and then there's a poll of if there's to get the stuff. How does OpenGL ES work? OpenGL ES is just a different OpenGL version, so it's not a platform part, it's a subset of OpenGL calls that are allowed to... So you have the platform there, that's GLX, WGL, CGL and then you have on top of it either OpenGL itself or OpenGL ES, which is a subset of I think the 2.0 is for OpenGL 3 and OpenGL ES 3.0 is for OpenGL 4.0 or something like that, a mobile subset. So there are some problems with the different platform APIs. So Apple decided that it only supports OpenGL 2.1 or OpenGL 3.2 whereby they removed in OpenGL 3.2 the support for all deprecated features. So the fixed function pipeline that I mentioned that has been deprecated for years now is not available anymore and in OpenGL 2.1 many of the newer features are just not available yet. So you have to more or less select which version you want to support so it also means for us at the moment that we have to choose between the two for our code. So for old code 2.1 and for new code more or less go with 3.2. On Linux we have many old systems so I asked from the mailing list once for people sending out their GLX info which gives you the information which extensions are supported which OpenGL version is supported which GLX version is supported and there are surprisingly many people who still use OpenGL or only have hardware and drivers that are able to support OpenGL 1.04 or OpenGL 2.1 So the problem there the best support is only available so OpenGL 4.0 or something is only available with proprietary drivers and this version only supports 3.3 so even the one that's in front of the door or something like that and on Windows you don't have support for rendering or binding a context to multiple threads so you have to make sure that the thread is reset before you use it in another thread So dealing with OpenGL is quite hard if you do it directly if you don't abstract it you can only use the OpenGL version that's supported on your base platform you do a lot of metrics operations vector operations and of course we want some support for that so we use two libraries to openGL extension render it abstracts loading the function pointer for OpenGL calls and that's that once instead of you doing it manually before you use them but it only works after you have a working OpenGL context so for all the calls that you need before the context is loaded you need to load them manually it helps with extensions OpenGL features OpenGL versions because you have a variable that says if the extension or version is there or not and you just check make it an if instead of an if def which would result in a build time dependency instead of a run time dependency It's quite easy to use it the build system I just use it as a put it into external libraries and include the clue header instead of the normal OpenGL header which then does all the work for you also OpenGL context initialize to when you create the context the other one is GLM it's OpenGL mathematics it's used quite a few projects the header-only template library that provides vector and matrix operations it therefore helps you with all your model transformations few transformations all that stuff that you have to some degree and base GFX but the advantage is that it's layout compatible with GLSL shaded language by OpenGL it means many more algorithms than we have it's better tested than maintained and we can replace a huge part of our base GFX code with GLM I already did it for the OpenGL transitions and it was quite straightforward so how do you use OpenGL now in the process as I mentioned you need to decide on a version that you want to support in your first step so a 2.1 legacy context or a 3.2 core context the OpenGL context class has a flag to tell it I want a legacy context change the make file you need to include GLR GLM normally OpenGL frameworks they are platform dependent and you need a pointer to your pan window because OpenGL only renders to windows and a context is normally bound to a window exception is Mac where the whole system uses OpenGL but if we want to support a feature on our platforms we need a window for it then you create your OpenGL context it needs either a window pointer or a system child window there are some cases where it makes sense to create the system child window itself if you don't pass the system child window it will create one itself where it finally gets a handle for the system for the wheel window provided by the system I think Tamash uses that because it needs a special system child window that creates a platform dependent context that is taken mostly from you at the beginning of your OpenGL code you need to make the context count so there is a make count method it tells the OpenGL code to use this context now for the following codes and make sure that your code is only ever one in one single thread so if your context might be used in multiple threads you need to unbind it at the end of your course you have one of these at the moment that's used in two threads and you have to be really careful or everything can go wrong it's totally undefined the idea but suddenly it breaks on the map or windows that can even kill your graphic card driver so then comes the next step if you decide on a 3.2 core context you should be trying to be deprecated where it documented all the OpenGL features that you should not use in a 3.2 context because they are not available on the map read existing shader code shader code is at the moment in chart 2 OpenGL slideshow OpenGL in canvas OpenGL it's quite helpful to read existing code many of the existing problems are already solved might just be able to use it at installation time they end up in the OpenGL program so all of them end up there and will be loaded in runtime from there a quite helpful class is OpenGL helper we are expected all the helpful OpenGL code like loading a shader compiling the shader it's all done there creating a frame buffer object error reporting rendering to a file some logging stuff and it's the place where you should add shader code so if you think the same code will be used in at least 2 places edit there it only needs static methods because OpenGL is more or less the stage is stored in the context and not in the class so which foot features are already in using it so we have 4 different features that are working with it the 3D models I hope everybody was in tamas talk they use libgltf and use our OpenGL context for that but the whole OpenGL calls itself in an external library and it works surprisingly well but I think it requires OpenGL 3.0 I can't get back that then my 3D chart that will be available in 4.4 I will talk a bit more about them tomorrow sadly they are broken on master after my last ticknotch so I did not be able to show it tomorrow but you can see my amazing 3D chart a few weeks ago and OpenGL transitions they have been in the code for quite some time I fixed them so they work now on windows and use the same implementation for all 3 platforms they are much faster than it is now finally for something usable on most machines I ported them to GLM already so it was just a masked copyright replace and switched from double to float which helped the performance quite a lot so if you work with OpenGL use float GPU is really really bad double please test it I actually introduced a dozen repressions if you know my code you know how bad it is so the OpenGL canvas that's Torsten's baby I don't know if he is here oh yeah yeah it's a joint layer canvas it's an experimental implementation to show what would be possible it builds already on all 3 platforms but running it results in nasty pressures I wasn't unable to fix the first one before I gave up it needs a lot of it needs more work but it would help us to improve the performance by the bit especially on Mac where we currently fall back to the BCL canvas on Windows we have Kyro and DirectX canvas which is quite fast so what we can do in the future with OpenGL as was discussed in the last session the idea is to finish the OpenGL canvas as one part and implement an OpenGL backend in BCL so that more or less the whole application would use OpenGL as backend which would help especially on mobile platforms get rid of the its dependency here bring some of the workload from the CPU to the GPU that we don't use that much and therefore improve the performance otherwise I might use it for some more 3D charts at the moment it's mainly the 3D bar charts which act more as a demo than a feature but it looks quite nice and with some abstraction it might even be possible that the 3D model our stuff into drawing there was similar library that then offloads it to OpenGL so that we could create some easier 3D scenes without needing to worry about OpenGL but still having the performance of OpenGL in the backend yeah, otherwise I don't have any plans except for putting the stuff to Android and iOS which would finish more or less at the lower level and make it possible for us to use the same code across all platforms ok that's it, thanks any questions?