Problem with 2 GLCanvases on IntelGMA965
BlitzMax Forums/Brucey's Modules/Problem with 2 GLCanvases on IntelGMA965
| ||
Hello, Seems there's still issues with this card in my editor, and the problems replicated with this sample: That's the glMax2d sample that comes with wxMax that I've modified to show 2 clocks side by side on separate canvases. Of course you probably won't see what's happening unless you have Intel GMA965 graphics, but basically only 1 clock updates at any one time. Sometimes you can switch which clock updates by maximising/restoring etc., but only 1 will ever update - kinda weird :) Definitely all the latest drivers being used, so I'm just wondering if anyone has any ideas for possible workarounds - aside from using wxDC instead. Not sure if it's a wxMax problem or the same thing happens in MaxGUI... |
| ||
Yeah, works fine on my GMA950... (Mac Mini) |
| ||
Works in Parallels too, unfortunately.... I guess we need a MaxGUI example. I'll see if I can remember how to use it... |
| ||
Here's a MaxGUI version. I may have done something wrong though, as on my Mac, the right clock digits appear as solid blocks - which usually indicates a lack of VRAM. (forgot how much I dislike the non-OO interface) <EDIT> Looks like an OS X issue (above), as it runs fine on Win32 in Parallels. |
| ||
Brucey - its my laptop that TimelineFX doesn't like. Just tried the MaxGUI code above (with WINDOW_RESIZABLE flag added), both clocks run perfectly alongside each other. |
| ||
Great, I was thinking about a maxgui sample too, but was a afraid of delving back into it again. I'll see what happens with that, thanks :) |
| ||
its my laptop that TimelineFX doesn't like There's always one ;-) Hmm... it may be something to so with using shared contexts. GfK, did you have any issues with GLGraphics before Mark's latest "tweaks" - which did something with shared contexts, I think.... |
| ||
GfK, did you have any issues with GLGraphics before Mark's latest "tweaks" - which did something with shared contexts, I think.... There was an issue when I first got my laptop in Nov 07, where all graphics under GL were solid white squares. At the time Mark did attribute it to shared GL contexts but I don't recall him fixing it at the time. I think an Intel driver update a few months later fixed it. |
| ||
Ok. Well, I've got it doing something with shared contexts by default, so I'm going to hack things around a bit to not do that, and we'll see what happens. It's all a bit low-level for me, this GL stuff... so I've kind of been making-it-up-as-I-go anyway... |
| ||
Heh... I've removed the "sharing" aspect, and now it replicates the issue I had in MaxGUI on my Mac - that being the right-hand digits appear as blocks... So, I guess my Mac requires it to be enabled... However, I'll do a Win32 build with this and we'll see... |
| ||
If you can give this a whirl and see if it does anything : canvas_nonshared.exe.zip (2.1 meg) Thanks. |
| ||
It kind of works. Both clocks continuously run, but the digits on the right hand clock are black rects. I also get a windows error on exit; "canvas_nonshared.exe has stopped working". I *only* get this error if the app has previously been minimised to taskbar. Otherwise the app shuts down correctly. Wish Vista was a little more verbose with its errors. |
| ||
Same here Black rectangles on the right clock with XP and GeForce 7600 GS. Is this about glPushAttrib and glPopAttrib ? |
| ||
on the right hand clock are black rects Looks like the context needs to be shared after all. Was up til 00:30 last night trying to come up with a solution. Currently, I've got it only drawing one or the other... haw haw... Interestingly I can't see anything that stands out in the code that is wrong... :-/ |
| ||
Thanks for looking into this Brucey :) Maybe it is something to do with the changes brought in 1.32: http://www.blitzbasic.com/Community/posts.php?topic=83917#947391 And then this post about the context sharing command: http://www.blitzbasic.com/Community/posts.php?topic=83917#947706 |
| ||
I still haven't come up with a solution, despite rewriting the core of wxGLCanvas several times... If I had any hair I'd have pulled it all out several times by now :-/ |
| ||
Silly question.... can't you just use DX? |
| ||
Sure. You can grab the HWND for a window, and attach a graphics context to it. |
| ||
I'll have to weigh up the options then... I could try dx but all my routines to save animations are written in opengl (unless I can use both), and I guess that still wouldn't solve it for Mac users (for whenever I get Mac :). Other options are to redo the graph so it draws using a wxDC. I was also thinking of drawing the graph to the back buffer on the preview window, grabbing a pixmap of it, then just draw that on the panel, not sure what the speed would be like tho. |
| ||
I have thought about making custom wx widgets that would use Max2D. It would allow me to create a bit more appealing visual look. Is there any theoretical reason why I should not? Any kind of limitations such as the bug discussed on this thread? Using DX is no problem for me. |
| ||
The issue here is the only thing I ran into personally, the more shared contexts you have though the worse it might get for other cards. I had similar problems on my works PC with an ATI 9500 so I converted the controls to use wxDC instead. I think I might just go ahead and do that for the graphs too. |
| ||
Thanks for sharing. I'll stick with wx based drawing for widgets. |
| ||
So, I've now converted the graphs to use wxBufferedPaintDC so they're happy now. The only problem left is preview window messing up when minimising/maximising. I'm trying to get it to reset things after a maximise/restore event, but the wxEVT_MAXIMIZE doesn't seem work, wxEVT_ICONIZE works fine tho, I'm usingconnectany(wxEVT_MAXIMIZE, onMaximize) Is that right? |
| ||
Hmm, I think wxTopLevelWindow is missing some events... which would be a bit of an oversight. |
| ||
But, on the otherhand, I think a wxSizeEvent is generated when a window is restored from its iconized form. |
| ||
Well, I've now implemented wxMaximizeEvent, but it doesn't seem to be generated anywhere, which is kind of odd. wxSizeEvent is generated on a Maxmize/Restore cycle though. |
| ||
Thanks Brucey, got another problem though, but I'm probably doing it wrong...If i useconnectany(wxEVT_SIZE, onMaximize) then that works when the window is maximised, but the window doesn't redraw itself properly, I'm guessing I'm overriding the normal resize event that handles all that... |
| ||
Try adding an event.Skip() |
| ||
Thanks. Actually I'm being a bit daft anyway, I just noticed I was already checking for a size event on the actual canvas itself to resize the viewport each time, doh! So I can just use that :) |