GLShareContexts() issue
BlitzMax Forums/MaxGUI Module/GLShareContexts() issue
| ||
| Short version: I either need to be able to turn OFF GLShareContexts() after I turn it on, OR I need to be able to draw multiple canvases without turning it on at all. GLShareContexts() is not well supported on all graphics cards so it should be avoided, however I have 3 canvases, and they need to share a lot of images... GLShareContexts() is working fine for this except that it causes MiniB3D to crash on one of my tester's systems... Short term fix, is there a way to turn share contexts OFF once you've turned it on? even if it requires resetting the graphics driver (which doesn't seem to work)? I can't find any way to get it off once it's been enabled without exiting the program... Is there an alternative to shared contexts for re-using TImages? I don't need to retain the backbuffer for each context, so in theory do all the images belong to one context (It would appear the last one that was set via SetGraphics()...), which I could draw in, and then flip that to the area I need to display? |
| ||
| Is there a specific reason why your canvases need to be divided into three? For fear of stating the obvious, if they are next to each other, maybe you could just merge them together as one canvas and add the split screen logic to your rendering code. Otherwise I'm stumped. Not really a GFX programmer. |
| ||
| turning it of is no realistic option, that tripples the amount of VRAM and if he really has such a crap card that he requires it to be turned off I've to say that I am not sure if it runs on that system at all. TImages are basically TPixmap + VRAM representation. The Pixmap is totally API / context independent so no problem there. But the VRAM representation will be context dependent. |
| ||
| the contexts are split up as seperate GUI elements, they have scroll bars attached to shift their contents, each is used for different things (one shows and allows re-ordering of thumbnails, one selects a modifier for the thumbnails, one show and allows re-ordering of groups of thumbnails...) but they are all distinct, they also get re-drawn at different times, so if possible I'd like to not have to draw all 3 every time any of them needs a change. The problem with the shared contexts is not that it specifically is a problem. but when I try to go to full screen 3D in minib3d after closing down and releasing the window then on one computer it crashes. if I never turn on shared contexts then (obviously) my GUI elements are all fubar but the 3D switchover works fine. So basically if I could turn GLShareContexts() off when I'm done with it, and switching to 3D, I shouldn't have a problem... but I see no way to turn it off... so I'm looking for that or alternatives. And you're right, trippling the vram usage, even if it were possible would just cause many many more nasty nasty problems... |
| ||
| I've gone digging through the source for brl.glgraphics and I've hacked together something that seems to be working so far... basically when you setup shared contexts it creates an extra opengl context that all of the display contexts use to store their data (since they all use the same place for storage it's available to all of them). When you create a new context it tries to incorporate the share context at setup. if the share context is missing it doesn't use a share. The following will release the share context and set it back to nil so new contexts will not use it. So far this has gotten my tester running, however he has noted some graphical glitches but I don't know what/where/when yet. And that was also on my first test I sent to him. This WILL cause some bad things to happen if there's any context available when you call it so you should end everything before you call it. Also, as noted by dreamora, timages have a VRAM managed component. You should clear all your images and preferably call GCCollect() before killing the shared context as well, otherwise stuff could be left behind and get loose... Might cause a memory leaks, haven't had a chance to test that yet. Obviously use at your own risk and if someone else with more openGL experience want to point out how this might cause disasters, or improve it in any way please do. So far I only have it working on mac, the windows brl.glgraphics is far more intimidating, and I haven't even looked at the linux code yet... Add this to mod/brl.mod/glgraphics.mod/glgraphics.macos.m
void bbGLKillGraphicsShareContexts(){ // destroy shared context hack by ima747
if( _sharedContext ){
[_sharedContext clearDrawable];
[_sharedContext release];
_sharedContext = nil;
}
}
Add this to mod/brl.mod/glgraphics.mod/glgraphics.bmx ?MacOS Rem bbdoc: Dissable OpenGL context sharing about: This clears the shared context created by GLShareContexts. It should be called after all opengl contexts are removed. Mac os only End Rem Function GLGraphicsUnshareContexts() bbGLKillGraphicsShareContexts End Function ? Also at the top of the bmx file, in the extern declaration section add this ?MacOS Function bbGLKillGraphicsShareContexts() ? GLGraphicsUnshareContexts() is your new toy. Rebuild modules, cross your fingers and don't blame me if things go horribly wrong ;0) |
| ||
| Got to play on my tester's computer. It seems as long as I kill EVERYTHING I created before switching back and forth it works well... I have a nagging suspicion that I'm missing something important though... |
   |