Canvases don't redraw on resize/move.
BlitzMax Forums/BlitzMax Programming/Canvases don't redraw on resize/move.
| ||
| If I'm not mistaken, there is no way for me to redraw a canvas when a window is being resized or moved, because the app stops running when in this state and the events will not be parsed until after the move is completed. The logical fix for this is for BlitzMax to automatically redraw canvases in their last known state while the window is being resized or moved. But it doesn't do this... at least, it doesn't seem to do it RIGHT. When I move the window, the canvas moves with it, but as soon as I move it off the screen then move it back on, I get a "hall of mirrors" effect on the portion of the canvas that went off the screen until I release the mouse button so it can redraw. And when I resize the window, I have a panel behind the canvas, and it seems to draw that over the canvas. If I pull the right side of the window, blackness from the panel is drawn over the canvas moving from left to right starting at the left side of the window. Anyway, the details aren't really important. I'm sure you're aware the canvases aren't being redrawn, but why have you left it this way when you know we can't redraw them manually as the window is resized? It looks crappy! |
| ||
| Tried eventhooks yet? guess not..:P so: use eventhooks! |
| ||
| look at eventhooks http://www.2dgamecreators.com/maxgui/T15-Eventhooks.html. The thread where Mark responded to this issue: http://www.blitzmax.com/Community/posts.php?topic=53158 |
| ||
| I saw someone talking about canvases redrawing and they mentioned hooking events or something, and them not working. And why should they? The code stops when the window moves. Why would event hooks continue to be called? That would imply some sort of multithreading, wouldn't it? If that were the case I could hook a function to the timer event and have it run in the background simultaneously with my app and I've read Max doesn't support multithreading. |
| ||
| Well, I'll try it. But I'm certain I read a post saying it didn't work. |
| ||
| its not multi-threading its just hooking into the eventqueue |
| ||
| The code stops when the window moves. Why would event hooks continue to be called? The code doesn't stop when it's all eventhooked. Have a timer in a type that redraws its (type-)canvas with some effect, and the effect simply continues when you drag this window around. It ofcourse _doesn't_ continue when you don't use eventhooks, do it all with the global EventID() stuff, then things only work when you stop dragging around. Hence: eventhooks and eventhooked types |
| ||
| Hey it works! What do you know. :-) |
| ||
| Eventhooks work, though it would be fine if this would work "out of the box"! |
| ||
| Don't forget, that you can disable any window redraw on moving windows if you target your windows configuration to high performance. (on WinXP) |
| ||
| well, for me I have set it to high performance and classic gui, but enabled "redraw moving windows" as it looks cool. |
| ||
| It doesn't make sense for it to work out of the box. That's the whole point of event hooks. You HAVE to use a hook system in order to have proper updates like that, it's more to do with how the o/s implements things than how Blitz does. If you don't use a hook, the o/s is hogging all the cpu control and not giving it back to blitz so blitz can't do anything even if it wanted to. Without an event hook you can't interrupt that process. But you have to specify the hook yourself because the hook that actually runs has to be blitz code. I suppose they could provide a `default hook` that does some kind of basic updating of the display when the window moves or whatever. You will find though that event hooks DON'T work when you are resizing the window - TIMERTICK events don't come through, or any others, until you release the mouse button. You only get WINDOW_RESIZE events when the mouse stops moving, nothing else. If you want to tap into the o/s's control, make your own custom resize gadget so that TIMERTICK can continue to trigger. |
| ||
| "You will find though that event hooks DON'T work when you are resizing the window - TIMERTICK events don't come through, or any others, until you release the mouse button. You only get WINDOW_RESIZE events when the mouse stops moving, nothing else. If you want to tap into the o/s's control, make your own custom resize gadget so that TIMERTICK can continue to trigger." What are you TALKING about? I suspect you're the one whose message I read and fogured I could not redraw the canvas with this method! The way you're talking about it it sounds like redrawing the canvas would be impossible. But I have tested it now, and it is definitely possible. So eventhooks DO work when you are resizing the window. I can't comment on whether specific events come though, but the canvas redraw events definitely do, and constantly while the mouse button is held down, not only when you release it. |
| ||
| Hey, don't be so sure you are perceiving the full story here. Maybe that is windows-specific behavior. On the Mac there is only an event generated when the mouse stops moving or the button is released. I've tested it out myself. Nothing else can update while you're resizing the window. All TIMERTICKS and GADGETPAINT and all other events are blocked except WINDOW_RESIZED. Period. So maybe it is platform specific. Maybe they have some kind of bug in the mac version? |
| ||
| Angel: Ah you're talking about Mac. Well... you need to specify that because 99% of people here are coding for Windows! :-) Okay, well in that case, that sounds like a bug since Max is supposed to work the same on both systems. Maybe it is something they can't work around though because of how the Mac works. I dunno. Well this looks like something that should be posted in the bug forum then. Too bad someone moved the message out of the bug forum prematurely! |
| ||
| 99.99% are windows users to be precise... ;) And thanks to Assari I use event hooks in my mega gui app as well. Another issue I faced was that the update itself sometimes gets out of sync. Mark pointed "flip 0" out as a workaround. |
| ||
| Say, I missed this thread! The HOM effect when dragging a window around in Windows is still on my to do as when I asked this over a month ago no one knew how to solve it. sswift: Any chance you can post the code that worked for you in the end? It should be noted that the HOM effect occurs when using Graphics 0 (which I'm using) so I'm not sure if the hook code will work ... |
| ||
| Grey: You need to have a canvas to fix the problem I think, and that means MaxGUI. Then again, maybe you can just flip normally. But you may have to check to see if the graphics mode has been initialized or something. I could post the code to set up the window but it's still not working in it's entirety because of the DX driver issue, and I don't think you're interested in that anyway. Here's the code that fixes the canvas. App.Canvas is just a global variable with the canvas pointer. I had to check if it was null or else the app crashed when starting up. I'm not sure why, but I guess the event got triggered somehow before the canvas was created. AddHook EmitEventHook, MyHook Function MyHook:Object(iId:Int, tData:Object, tContext:Object) Local Event:TEvent=TEvent(tData) If App <> Null If (Event.Source = App.Canvas) And (Event.ID = EVENT_GADGETPAINT) Flip Return Null EndIf EndIf Return tData End Function |
| ||
| sswift: I see thanks. I'll have to see if that can be made to work for a non-canvas window but still in windowed mode. It will have a canvas I'm sure, but I'll have to find it via windows API. |
| ||
| Yah well, since BlitzMax is cross-platform let's not just assume that everything is true if you're a window's user, if it is behaving a certain way in BlitzMax that means maybe it's doing it on any of the three/four platforms, not just the little isolated world of windows ;-D That aside, it's good to know that it does seem to work ok on windows and that maybe it will work on the mac soon too. I think I already posted this issue to the bug forum, or at least made it a feature request. Another problem the Mac has is that if you have a MaxGUI window with no titlebar, CanvasGraphics() doesn't work and leads to a crash. Hopefully that'll be fixed soon. |
   |