Freezed graphics when moving a windowed game

Hi,

After a long time of coding on a game a tester mentioned my game to freeze the graphical output when he drags the window of the game and tries to move it around.

As long as a user is moving the window around, there is no redraw of the surface and also no processing of code. In Singleplayergames this would not disturb but on networkgames problems occour with receivepuffers getting too much input.


So my question is, how I could force my game to process messages and redraw graphics (and so on) while a user is moving the windowed game around the desktop.


I already tried some lines of code with event hooks but EVENT_WINDOWMOVE isn't recognized (only Appterminate, Appresume...).

If I'm forced to forbid windowmovement for the users, how would I achieve this?


bye
MB

You should use hooks, and a graphic canvas to solve this particular issues.

I doubt there's a solution, cause every game I know halt graphics while dragging the window.

EVENT_WINDOWMOVE isn't recognized? BMax v1.24 does. Also processing is not suspended using hooks.

Strict
Global Window:TGadget = CreateWindow("Test",10,10,320,240)
Global Canvas:TGadget = CreateCanvas(0,0,320,240,Window)
Global Timer:TTimer = CreateTimer(30)
Global x:Int = 0
AddHook EmitEventHook, MyHook


Repeat
	WaitEvent()
Forever

Function MyHook:Object(id:Int,data:Object,context:Object)
	Local Event:TEvent = TEvent(data)
	Print Event.ToString()
	Select Event.id
		Case EVENT_WINDOWCLOSE
			End
		Case EVENT_GADGETPAINT
			SetGraphics CanvasGraphics(Canvas)
			Cls
			DrawOval x-5,115,10,10
			Flip
			Return Null
		Case EVENT_TIMERTICK
			x :+ 2
			If x >= 320 Then x = 0
			RedrawGadget Canvas
			Return Null
	End Select
	Return data
End Function

I did find, at least on earlier versions (untested recently) that, on the Mac, when you drag the window title bar, all other events stop being transmitted to the event hooks until you let go of the mouse button. For an event-based app this basically means the whole refresh from the timertick event halts completely until the drag is stopped and the mouse is let go. The only way I found to get around this is to do away with the system title bar entirely, implement my own `drag zone` and process the individual mouse-down and mouse-up events which moves the window if initially clicked within the title bar zone. The same I found to be true of the window resize, that it was not letting all the events through until the window stopped being resized (ie mouse stopped moving). To get around that I implemented my own resize gadget. Obviously it won't look the same as the native system gadget unless you somehow grab that into an image to use in the corner of your canvas.

I don't know if this has been fixed or changed since, this was a MaxGUI issue.

I get a pause on the PC with this. If you click on the title bar the Gadget paint does not happen for a short while (data 452 - 466) . Works fine on the mac though. Anyone else get this?

TimerTick: data=449, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=450, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=451, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=452, mods=0, x=0, y=0, extra=""
TimerTick: data=453, mods=0, x=0, y=0, extra=""
TimerTick: data=454, mods=0, x=0, y=0, extra=""
TimerTick: data=455, mods=0, x=0, y=0, extra=""
TimerTick: data=456, mods=0, x=0, y=0, extra=""
TimerTick: data=457, mods=0, x=0, y=0, extra=""
TimerTick: data=458, mods=0, x=0, y=0, extra=""
TimerTick: data=459, mods=0, x=0, y=0, extra=""
TimerTick: data=460, mods=0, x=0, y=0, extra=""
TimerTick: data=461, mods=0, x=0, y=0, extra=""
TimerTick: data=462, mods=0, x=0, y=0, extra=""
TimerTick: data=463, mods=0, x=0, y=0, extra=""
TimerTick: data=464, mods=0, x=0, y=0, extra=""
TimerTick: data=465, mods=0, x=0, y=0, extra=""
TimerTick: data=466, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=467, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=468, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=469, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""
TimerTick: data=470, mods=0, x=0, y=0, extra=""
GadgetPaint: data=0, mods=0, x=0, y=0, extra=""

I tried it with the update from 1.22 to 1.24 (inclusive syncmods and recompiling them) - no change to see.


I just want an as simple as possible solution to force a "processmessages" when the window is being moved around.

@TomToad - I'm not using maxgui

@ziggy - could you please be so kind and give me an working example of your suggestion? If not possible and before I forget - thanks for your nice IDE (0.8.08 gave an big speed improvement although the old engine loaded a lot faster)

@AngelDaniel - On Linux there isn't such an odd behaviour, if the window is moved around the content (graphics) are updated with a small delay - but processed is processed.


bye
MB

I looked into this for my framework but there is no obvious solution without a lot of jiggery pokery.

EVENT_WINDOWMOVE is working in 1.24 here.

If I replace EVENT_TIMERTICK in the above example with EVENT_WINDOWMOVE. The ball only moves if I move the window.

@Mystik - I'm not using Maxgui (so no access to "TGadget") - and wether used PollEvent or WaitEvent, I never got the Event for Event_Windowmove, just AppSuspend, AppResume and so on are working.

And like I wrote: I updated to 1.24

Edit: Okay, the thing with the canvas wont bring me success in this (I think its an maxgui thingy). So other solutions?

bye
MB

Strict
Framework brl.blitz

Import brl.d3d7max2d
Import brl.glmax2d
Import brl.timer

Global Ending
Global Timer:TTimer = CreateTimer ( 60 )
AddHook EmitEventHook , Hook
AppTitle = "Rotating Rectangle"
Graphics 400 , 300
While Not Ending
  WaitSystem
Wend

Function Hook:Object ( id , data:Object , context:Object )
  Local Event:TEvent = TEvent ( data )
  Select Event.source
    Case Null
      If Event.id = EVENT_APPTERMINATE
        Ending = True
      EndIf
      If Event.id = EVENT_KEYDOWN And Event.data = KEY_ESCAPE
        Ending = True
      EndIf
    Case Timer
      If Event.id = EVENT_TIMERTICK
        Cls
        SetRotation Event.data
        DrawRect 200 , 150 , 100 , 100
        Flip 0
      EndIf
  EndSelect
  Return data
EndFunction

I hope I could help you!

When playing a multiplayer game, make the window unmoverable.

Yes, I tried this on windows with some applications. It doesn't seem to be a BMX specific behaviour. Other applications, for example windows media player show the same behaviour. The problem is surely caused by the operating system.

If I remember, window move and resize return those events only when you stop the resizing movement (ie mouse comes to a rest) or you let go of the button.

I also recall that on a slower computer the o/s doesn't give enough remaining cpu time to the app for it to update the game very often while draggin the window, so it may appear to not be updating at all when it's really down to not enough cpu time to share. I found that on a faster computer the display actually would update while dragging.

I don't have a solution to offer you but just an observation.

I've always known this to be standard behaviour on Windows systems going all the way back to Win 3.1 so is it really a problem to be solved?

Anyone who's used Windows for any amount of time will now about and expect the action to freeze when dragging a window about.

In fact, just positioning the mouse cursor over the minimize or close button will cause the app to freeze for a second as the balloon tip pops up.

So maybe you really don't need to fix this.

I agree with CGV, Just make the window boaderless in multiplayer games

Sorry, but I'm getting different results here, for all the three situations. Regardless whether I use a window messages spy app or I write a MaxGUI app dumping out events, I always receive window move messages/events, also if the mouse doesn't come to rest.
I couldn't find any windows application, which doesn't repaint the window's contents while dragging (except some BlitzMax and BlitzBasic applications).
And on my windows, the tool tip also comes up, without causing any applications to freeze. The only situation where I can confirm the freezing is when you click on the window's title bar and hold down the mouse button for a while, but don't move the mouse in this tme.

I could test only on one machine, WinXP Home with Sp2, but I supposed this was the default for all windows systems.

Personally I would avoid to make the window borderless and unmovable, since it's not that user friendly.

p.s.: doesn't the code above solve the problem?

@fabian - I tried your example code - works fine.


I tried to implement it in my code and from then I wasn't even able to move the mouse around - neither in the window nor in the title-area. Also strokes on the keyboard aren't recognized.

So I tried to add some events for keydown events - no change.

Function Hook:Object ( id , data:Object , context:Object )
  Local Event:TEvent = TEvent ( data )
  Select Event.source
    Case Null
      If Event.id = EVENT_MOUSEMOVE
	    Print "mousemove"
        MOUSEMANAGER.changeStatus()
	  EndIf
      If Event.id = EVENT_APPTERMINATE
        Ending = True
      EndIf
	  If Event.id = EVENT_KEYDOWN
	    Print "keydown"
	    KEYMANAGER.changeStatus()
	  End If
      If Event.id = EVENT_KEYDOWN And Event.data = KEY_ESCAPE
	    Print "esc"
        Ending = True
      EndIf
    Case mytimer
      If Event.id = EVENT_TIMERTICK
	    DrawMain()
      EndIf
  EndSelect
  Return data
EndFunction

Because of not recognizing keystrokes or klicks on [x] I also tried to close it by the contextmenu - but in this case its an empty one (no items to click on) which forces me to kill the program using the task manager.

EDIT: I removed some lines of code (something which is now commented out makes it stop working - but this will be another subject which does not fit here - and which I will find out myself - I hope ;D) and I think your source is working pretty well (ok it gets kind of slower while being dragged - but its a start)

EDIT2: I uncommented my first commented lines of code - and now it works (no changes made) - very strange. But as long as it works.

Big bags of thanks to fabian.

bye
MB

(sorry for double post but if one of you read my last post already - I don't know if "editing" refreshs the last post-date).

Fabian's Code is working pretty well on newer graphiccards.

Some of my users wrote about not moving mousecursors and so on - after he posted he uses an old sis 650 onboard graphic card I tried on an old pc with the same sis-card.

The result was the same: the whole game doesn't respond - even if I switched a section with much less graphics. On parts of the Code where I'm not using Fabians Code (parts where I'm not able to move the window ;D) everything works well on my 4 test pcs and the computers of some testers. So I tried and tried and finally lowered the timer-intervall to 30 ... it's just the graphic card not being able to do it as fast as I want (60 fps). The most common graphics I use have an maximum Pixelcount of 80000 (eg 800x100) but most graphics are 40x60 or so.

So if one uses Fabians code and does some fancy graphical things on screen - remember to decrease framerate if the pc seems locked down although the cpu-usage is lower than 20% (I know it's just an average value).

EDIT: it's just the choppy graphic card ... even the old waittimer-method shows a slight slowdown every X frames... it doesn't bother if using dx or ogl.

bye
MB

Hi,
excuse the late answer, I tested the code on another machine and saw the problem, it seems to be caused by the application's timer. The timer posts events regardless whether the event processing code is fast enough to process these events. So in the example above the drawing code seems to take more than 1000/60=17 milliseconds to be executed. Therefore the timer posts the next event before the previous one is processed, the result is that the application's message queue overflows and the gui messages, which are needed to react the close button, open the context menu, setting the cursor and so on, can't get processed.
To solve this problem it would need another timer in the application, since the BlitzMax timers can't change the frequency while running.
This timer posts the next timer event not until the previous was processed. Therefore the message queue doesn't contain timer events while the application draws the window's contents, and in this time the gui events can be processed.
Sadly I've no access to a linux or macos, therefore I could write this timer only for windows:

Strict
Framework brl.blitz

Import brl.d3d7max2d
Import brl.glmax2d

Global Ending
Global TimerHertz = 60
Setup
SetTimer Max ( 1000 / TimerHertz , 1 )
AddHook EmitEventHook , Hook
AppTitle = "Rotating Rectangle"
Graphics 400 , 300
While Not Ending
  WaitSystem
Wend

Function Hook:Object ( id , data:Object , context:Object )
  Local Event:TEvent = TEvent ( data )
  Select Event.source
    Case Null
      If Event.id = EVENT_APPTERMINATE
        Ending = True
      EndIf
      If Event.id = EVENT_KEYDOWN And Event.data = KEY_ESCAPE
        Ending = True
      EndIf
      If Event.id = EVENT_TIMERTICK
        Local DrawStart = MilliSecs ( )
        Cls
        SetRotation Event.data
        DrawRect 200 , 150 , 100 , 100
        Flip 0
        Local DrawStop = MilliSecs ( )
        Local DrawTime = DrawStop - DrawStart
        Local TimeLeft = Max ( 1000 / TimerHertz - DrawTime , 1 )
        SetTimer TimeLeft
      EndIf
  EndSelect
  Return data
EndFunction

Global Wnd
Global Ticks

Type TWinClass
  Field Style
  Field Proc:Byte Ptr
  Field ClsExtra
  Field WndExtra
  Field Instance
  Field Icon
  Field Cursor
  Field Background
  Field MenuName:Short Ptr
  Field ClassName:Short Ptr
EndType

Function Setup ( )
  Local Class:TWinClass = New TWinClass
  Class.Proc = Proc
  Class.ClassName = ( "CLASS#" + Int Byte Ptr Proc ).ToWString ( )
  RegisterClassW Class
  Wnd = CreateWindowExW ( 0 , Class.ClassName , Null , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 )
  MemFree Class.ClassName
EndFunction

Function SetTimer ( millis )
  Ticks :+ 1
  timeSetEvent millis , 0 , TimeFunc , Ticks , 0
EndFunction

Function TimeFunc ( Timer , Msg , User , DW1 , DW2 ) "Win32" NoDebug
  PostMessageW Wnd , $400 , User , 0
EndFunction

Function Proc ( Win , Msg , WP , LP )
  If Win = Wnd And Msg = $400
    TEvent.Create ( EVENT_TIMERTICK , Null , WP ).Emit
    Return
  EndIf
  Return DefWindowProcW ( Win , Msg , Int Byte Ptr WP , LP )
EndFunction

Extern "Win32"
  Function DefWindowProcW ( Win , Msg , WP , LP )
  Function RegisterClassW ( Class:Byte Ptr )
  Function CreateWindowExW ( ExS , CN:Short Ptr , WN:Short Ptr , S , X , Y , W , H , P , M , I , LP )
  Function timeSetEvent ( D , R , P:Byte Ptr , U , E )
EndExtern

If it is important for your project to have a cross-plattform solution, I sadly can't help you. In this case you could make a borderless window, or you could make the game full-screen only.

Thanks - I'll have a look at the code now.

How would I achieve a borderless window (Linux and Win have to be supported - so windows would get a switch)? I looked through the help some days ago and have not found such an command.

Another very uhm... confusing thing is the fact that not all users with this problem are owning old graphic cards...and some with old PCs are not having problems...

So one uses the fairly "ok" graphic card "NVidia GeForce 7600 Go" - and has big slowdowns and "mouse does not respond" - others, with an 5 year old pc with cheap components are just saying "running smooth as cream".

I also reduced my loop-times - but although the whole loop is processed in about 7ms, it has problems when run with 60fps (420ms - smaller then the needed 1s).

While using the directx-mode the flip when big images are used (and capped by setviewport) is slightly faster than in maxgl-mode - using smaller images (other sections) the tide is turning and maxgl wins the race. Sometimes my code uses DrawRect (on the slow pc 12x the times of an image drawn with the same size) but finally I cut down the loop to use just the mentioned 7ms (on my pc it's lower than 1ms) with the flip using 5ms of those 7ms.


uhm... before I'm writing too much I will better finish this posting.

Thanks Fabian,


--- for Fabian also in German (so that I would not run into problems for just translated my thoughts the false way) ---

Ich werde mir den Code mal anschauen

Wie ist der Befehl (ohne Maxgui) zum entfernen des Rahmens, als Alternative hatte ich mir das schon ueberlegt, da sowohl Linux als auch Windows unterstuetzt werden sollen und dann per Schalter entschieden wird, ob bestimmte Routinen anlaufen. Ich habe zwar vor ein paar Tagen mal durch die Hilfe geschaut aber einen solchen Befehl nicht entdecken koennen.


Was aber irgendwie doch... verstoerend wirkt, ist die Tatsache, dass nicht alle User mit diesem Problem auch gleichzeitig einen alten PC haben - und andersherum haben User mit alten PCs nicht immer obige Probleme.

Einer hat beispielsweise die halbwegs brauchbare (Notebook-)Grafikkarte "NVidia GeForce 7600 Go" und er hat grosse Ruckler und das "Maus reagiert nicht"-Problem.
Andere hingegen haben einen 5 Jahre alten PC mit Uralt-Komponenten und schreiben als Kommentar nur, dass es fluessig laeuft und keine Probleme auftreten.


Ich habe auch die Zeiten reduziert, die fuer die jeweiligen Prozeduren anfielen - und obwohl die Gesamtschleife in etwa 7ms abgearbeitet wird, gibt es Probleme, wenn mit 60fps durchgerattert werden soll (und 60*7ms = 420ms was weit weniger als die notwendige 1s ist).

Waehrend im DirectX-Modus der Flip bei der Nutzung von grossen Bildern (die per SetViewPort abgeschnitten werden) schneller als im MaxGL-Modus ist, ist es bei kleineren Bildern (also anderen Bereichen des Spieles) genau andersherum und MaxGL ist der Sieger.

Ebenfalls ist mir aufgefallen, dass DrawRect auf meinem langsameren PC (der mit der Sis 651) etwa 12x so langsam wie das Zeichnen eines gleichgrossen Bildes ist.
Mittlerweile habe ich den Gesamtdurchlauf auf unter 7ms gedrueckt (auf meinem unter 1ms) aber der Flip benoetigt immernoch 5 der 7ms.

So, bevor ich noch mehr Senf von mir gebe, beende ich lieber diesen Beitrag.

Nochmals Dank an Fabian,

bye
MB

I wonder if you really don't need a second timer, you could implement your own queuing system, use the hooked event code to deal with receiving new events and putting them in an internal queue and when extra time is available allocate it to processing them?

Sure I could try to do this - but this seems not to be one of the (simple) solutions I thought to find in all your answers.

The solution of Fabian may work but as long it's just a thing working for windows I can't use it.

Another problem was that some users experienced the "blocked mouse movement" when using the normal waittimer-method (not the hookevent-method) - so vice-versa I run into trouble which may fall into off-topic.

Additional I wonder why brl doesn't implement it in max2d - I think it's more than in humans nature to move a windowed application sometimes (eg a window of an instant messager pops up and has to stay next to the games window) - and to stop a networkgame each time isn't the user friendly way.


Thanks to all - nice to see many people willed to help

bye
MB

Why don't you just disable the timer while processing the timer event, and enable it again when the event has been procesed?

Redrawing window content while moving the window only happens if the user enables this.
By default is it disabled and the users would have to manually enable it. (this is for XP, don't now if the abandoned windows versions support it at all)

So what you could do is check at the timertick if a gadgetpaint has happened, if not, delay for the rest of the timer ticktime and recheck again (-> implement "pause on window move")

I also thought about this, it would solve the problem, but I was too scared that it could cause too much system overhead to create and delete the timer permanently. The code I wrote above is just such a timer which fires only once, till you recreate it. But as you said this I tried to do so and it works! Thanks, it looks like the problem is solved now, at least my tests showed me this, but let's hear what Michael says.

Strict
Framework brl.blitz

Import brl.d3d7max2d
Import brl.glmax2d
Import brl.timer

Const HERTZ# = 60
Global Ending
Global Timer:TTimer = CreateTimer ( HERTZ )
Global Rotation
AddHook EmitEventHook , Hook
AppTitle = "Rotating Rectangle"
Graphics 400 , 300
While Not Ending
  WaitSystem
Wend

Function Hook:Object ( id , data:Object , context:Object )
  Local Event:TEvent = TEvent ( data )
  Select Event.source
    Case Null
      If Event.id = EVENT_APPTERMINATE
        Ending = True
      EndIf
      If Event.id = EVENT_KEYDOWN And Event.data = KEY_ESCAPE
        Ending = True
      EndIf
    Case Timer
      If Event.id = EVENT_TIMERTICK
        StopTimer Timer
        Cls
        SetRotation Rotation
        Rotation :+ 1
        DrawRect 200 , 150 , 100 , 100
        Flip 0
        Timer = CreateTimer ( HERTZ )
      EndIf
  EndSelect
  Return data
EndFunction

@dreamora - gadgetpaint sounds like maxgui (like I mentioned I'm not using it). If you think of the "repaint"-appeareance instead of just an dotted-rectangle on the old position of the window - it just repaints the image it has stored when dragging started

@Fabian - I'll have a look at your code tomorrow. At the moment I'm optimizing the maximum framerates (drawtext can be very time consuming and so on). After finishing those parts I'll try your code.


Thanks for your engagement also on weekends.

bye MB

' redrawgadget.bmx

Strict

Type TApplet 

	Method OnEvent(Event:TEvent) Abstract

	Method New()
		AddHook EmitEventHook,eventhook,Self
	End Method

	Function eventhook:Object(id,data:Object,context:Object)
		Local	event:TEvent
		Local	app:TApplet
		event=TEvent(data)
		app=TApplet(context)
		app.OnEvent event	
	End Function

End Type

Type TSpinningApplet Extends TApplet

	Field	window:TGadget
	Field	canvas:TGadget
	Field	timer:TTimer
	Field	image:TImage
	
	Method Draw()
		SetGraphics CanvasGraphics(canvas)
		SetViewport 0,0,GraphicsWidth(),GraphicsHeight()
		SetBlend ALPHABLEND
		SetRotation MilliSecs()*.1
		SetClsColor 255,0,0
		Cls
		DrawImage image,GraphicsWidth()/2,GraphicsHeight()/2
		Flip
	End Method
	
	Method OnEvent(Event:TEvent)
		Select event.id
		Case EVENT_WINDOWCLOSE
			End
		Case EVENT_TIMERTICK
			RedrawGadget canvas
		Case EVENT_GADGETPAINT
			draw
		End Select
	End Method
	
	Method Create:TSpinningApplet(name$)
		Local	a:TApplet
		Local	w,h
		image=LoadImage("fltkwindow.png")
		window=CreateWindow(name,20,20,512,512)
		w=ClientWidth(window)
		h=ClientHeight(window)
		canvas=CreateCanvas(0,0,w,h,window)
		canvas.SetLayout 1,1,1,1
		timer=CreateTimer(100)
		Return Self		
	End Method
	
End Type

AutoMidHandle True

Local	spinner:TSpinningApplet

spinner=New TSpinningApplet.Create("Spinning Applet")

While True
	WaitEvent
Wend

There's no freezing for me when I use the example code that comes with maxgui.

Read your last line - remember my phrase "not using maxgui", so the code won't work.



bye
MB

Ah, I assumed it was for MaxGui. I remember seeing a blitzmax example were it used plain out DirectX.