1.38 multiple windows, multiple canvases
BlitzMax Forums/MaxGUI Module/1.38 multiple windows, multiple canvases
| ||
I have a window with a canvas, it draws and works fine. when the user clicks that window is closed and it goes to another function that creates another window with 2 canvases, they draw fine the first time but after a couple of redraws they get blank spaces, or color blocks, or various other inexplicable glitches. If I don't create the first window/canvas and just go strait to the second one everything works fine. I am releasing the first window gadget before going to the second window function. 1.38 mac os intel 10.6.2, haven't tested on windows yet. Is this a glitch in 1.38 not releasing the graphics object for the canvas properly, or am I just being thick and not doing something to smooth the transition? |
| ||
Got a solution of sorts, if I reset the graphics driver SetGraphicsDriver GLMax2DDriver() before making each window it seems to work fine. |
| ||
Have tried: GLShareContexts before initializing you graphics? Otherwise only one canvas is supported. |
| ||
It could also be that you need to setviewport on the canvas each time you paint? |
| ||
I'm trying to avoid GLShareContexts as the program is branching into a full screen OpenGL based 3D view later and things get ugly when I'm not sure what openGL is doing regarding textures etc. also I read somewhere a while back relating to a 3D problem I was having that not all graphics cards (intels specifically if I recall) have some issues with shared contexts due to how they manage their memory. Probably would work for the canvases but would make the 3D... troublesome :0) I do set viewport on each canvas, as I need to for the 2 canvases on the second window, so it's a habit I cary over to all canvases. The graphics driver set at that start of each window is working fine for me right now. I need to set the driver on my windows build anyway as I was getting some other weird canvas bugs without it, and as I said above I go into openGL later full screen so not having D3D involved makes me more comfortable. Thinking about it a little more I think the corruption could be related to similar corruption in openGL text commands when you close a context and open a new one where the text would just be drawn as white blocks... I get the impression that the openGL driver tries to cary over data from one context to another even if you haven't told it to share contexts (possibly holdover code, as I believe a while ago the contexts were always shared, and now they're not as a result of that intel graphics problem...) |