Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Allegro5: Event Queue Delay Problem

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
Allegro5: Event Queue Delay Problem
pkrcel
Member #14,001
February 2012

Well, I seriously thought I simply did not notice this before but....I would have if the problem showed itself, it's simply impossible not to spot it.

There's surely something happening in between the threads that are filling up and draining the Queue.

Dunno why actually, this is far beyond my means right now (and for the foreseeable future)

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

GaryT
Member #14,875
January 2013

Sorry for the delay. Hadn't spotted this went onto page 3

Just to confirm: Are you getting the same results whichever version of the compiler you use, and no matter what you change, the problem still shows itself.

pkrcel
Member #14,001
February 2012

Oh, I was just trying it out with TDM-GCC 4.7.1 and I run into exactly the same problem, go figure.

I now seriously think that I were drunk in my previous trials and didn't notice the problem, 'cause I'm damn sure I tried with and without the al_draw_textf call.

Actually it DOES matter what I change, meaning that the aforementioned call to al_draw_textf solves the problem.

But I can't be sure on WHY it does indeed.

And I can't try this on an XP machine....

EDIT: weird typos

EDIT2: putting an al_rest(0.000001) solves the issue as well on my machine with both MSVC11 and TDM-GCC 4.7.1</code>

EDIT3: I've also setup a Timer, and used it to time the event_queue drain, with al_wait_for_event, and...well the problem persists IF I keep al_set_new_display_option(ALLEGRO_VSYNC, 1, ALLEGRO_REQUIRE), while if I comment out the VSYNC request it all works okay (input-wise, of course display is a bit jerky not being synched with vsync nor with the timer itself).

I'll stop for now, but MAYBE I'll be able to dabble a bit more into it.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

SiegeLord
Member #7,827
October 2006
avatar

pkrcel, are you capable of building your own Allegro binaries?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

pkrcel
Member #14,001
February 2012

I did, on my own PC, this one is my company's one and I used precompiled binaries.

EDIT: well okay, I mean this one I'm using right now.... ;D

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

GaryT
Member #14,875
January 2013

Well I can say for my XP computer at work after testing again this afternoon, it definitely has Never Ever displayed this problem at all.

Well if this isn't some kind of ALLEGRO glitch then I don't know what is.

I'm probably going to try reading the keyboard state for the most important keyboard presses, or just use a small al_rest() like you have found out.

Incidentally and I wasn't going to mention it in this thread: But I had another issue over a week ago using the mouse, and within my loop it was possible to end up in a situation where al_flip_display() was called, without having drawn anything new to the screen at all, and it caused a very similar unexpected delay.

It took me ages to find out this was the cause, and I ended up trying al_rest(0.001) which fixed the problem. The only thing is though I suppose using al_rest() for any very small amount of time, could cause issues on old computers which have relatively poor timers if they were to wait for say 0.010 as a minimum. I ended up just avoiding the possibility of the loop calling al_flip_display(), without drawing something first.

From your Edit3: Yes definitely, disabling Vsync stops any issues, but I want to use it though. (Some Face Not Been Invented Yet)

EDIT: Also yes, I found out that behaviour with al_wait_for_event() a timer and Vsync as well. I think I described it in an earlier entry in this thread. I bravely declared I believed there was a BUG with using Vsync in various ways. Perhaps there is. What do you think.

I'm leaving for home now. I'll refresh in 30 minutes. Edit :D

EDIT 2: I've just created a new Empty Project i.e. not CLR or Win32 just to be sure, but as you've already said, it makes no difference. :-/

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

GaryT said:

You can't possibly know that Vsync works just fine on every system on all Windows versions. Also it's unlikely that it's only my two Laptops that are showing the problem.

I didn't mean that vsync was guaranteed to work on all platforms, because it is not, and that is another reason you don't want to rely on it. What I meant was that vsync has no bearing on the event queue.

GaryT said:

Edgar said:

If the event queue is both simultaneously empty and backed up"

What does this mean. I've never believed this to be true. How can it be. The queue or anything else can't be empty and have something in it at the same time.

Don't be so literal. I meant that the queue is being simultaneously reported as empty yet its sources are backed up, hence it is backed up as well. It's obvious there are events not being processed in a timely manner.

@GaryT - why don't you attach your exe that exhibits this behaviour so others can run it. There's a really big attachment button above the post editor body.

Like I said, I can't reproduce this anymore. And the behaviour changed if I added or removed code, like an al_draw_textf call.

Edit

GaryT said:

From your Edit3: Yes definitely, disabling Vsync stops any issues, but I want to use it though. (Some Face Not Been Invented Yet)

Vsync shouldn't have anything to do with it, yet I replaced vsync with al_rest(0.16) and it doesn't lag anymore. The lag is still really hard to reproduce, and it only comes with a totally bare example. However, I added in a call to al_wait_for_vsync() and then the delay is gone.

If there is a difference between A5's auto vsync and al_wait_for_vsync that might account for it but the auto vsync likely uses al_wait_for_vsync. IDK, but I'll look at it more later.

Thomas Fjellstrom
Member #476
June 2000
avatar

And the behaviour changed if I added or removed code, like an al_draw_textf call.

That's typically caused by a memory/buffer under/overflow bug.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Arthur Kalliokoski
Second in Command
February 2005
avatar

@Thomas - if that was the case, where to even look for it?

http://en.wikipedia.org/wiki/Memory_debugger

They all watch too much MSNBC... they get ideas.

pkrcel
Member #14,001
February 2012

Guys, I've just rebuilt Allegro with MSVC11 to the last git.

Where to look for checking if the background thread is properly backing up the queue?

why don't you attach your exe that exhibits this behaviour so others can run it. There's a really big attachment button above the post editor body.

Actually I have his executable, he just shared it on a skydrive, you should be able to find it attached(....If I don't screw things up...are executables accepted as attachments?)

On my Win7 rigs the exe file shows lot of lag in input.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Okay, I tried the exe you attached, and it does it for me too. It is very noticeable. Whoever built it shouldn't use such a large window though, it overflowed my screen and I couldn't touch the title bar. Kind of annoying.

I'm getting the latest git setup to build, and I've downloaded a few memory debuggers that Arthur pointed out.

pkrcel
Member #14,001
February 2012

I concur.

I'll be damned but I have a further problme building ith the vorbisfile library....grrrr

EDIT: well, I'll just skip the examples and getback on them later....

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

GullRaDriel
Member #3,861
September 2003
avatar

Nobody ever passed this through gdb / dbx / whatsoever debugger ????

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

pkrcel
Member #14,001
February 2012

Define "this" ???

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

SiegeLord
Member #7,827
October 2006
avatar

That exe does not lag for me on Windows 7... what sort of graphics cards do you people have?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

GullRaDriel
Member #3,861
September 2003
avatar

I mean, you have a problem with some code, it's clearly not easily visible.

Anytime I have that kind of problem I shoot them with a debugger.

gdb, dbx, dbx -check all should have been tried a long time ago, seeing the amount of post in the thread.

What Thomas said is also right: when I hencountered a problem where a textprintf or debug release fixed it, it was memory corruption or pointer mess that I could kill with the debugger. Note that the app itself was not crashing.

I don't say the problem will be evident, but being sure of the state of your pointers / memory is a good start to kill funky behavior.

Edit: and with what SiegeLord says: what kind of video driver you also have with it ?

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

pkrcel
Member #14,001
February 2012

SiegeLord said:

That exe does not lag for me on Windows 7... what sort of graphics cards do you people have?

This made me curious, so I tried running it with the built-in intel graphics adapter and....it does NOT lag!

While running with the (defualt) NVIDIA GEFORCE 610M does indeed lag.

Then again, my work laptop has a built-in Intel graphics card as well, and DOES lag.

I don't say the problem will be evident, but being sure of the state of your pointers / memory is a good start to kill funky behavior.

Sensible advice, but please apply it to the actual case, because the User code showed no "hot" code whatoever, so we were trying to nail down the thing on an upper layer of abstraction, meaning we even questioned about allegro itself...

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

GullRaDriel
Member #3,861
September 2003
avatar

Edgar:

For the 'why' a debugger, thought the topic isn't directly related, I quote one from stackoverflow:

Mike Dunlavey said:

It took me a while to figure out how to do this under GDB, but here's what I do. Get the app running and change focus to the app's output window, even if it's only a DOS-box. Then I hit the Control-Break key (while it's being slow). Then GDB halts and I do "info threads" and it tells me what threads there are, typically 1 and 2. I switch to the thread I want, like "thread 2". Then I do "bt" to see a stack trace. This tells me exactly what it was doing when I hit Control-Break. I do this a number of times, like 10 or 20, and if there's a performance problem, no matter what it is, it shows up on multiple samples of the stack. The slower it makes the program, the fewer samples I have to take before I see it. For a complete analysis of how and why it works, see that link. P.S. I also do "handle SIGINT stop print nopass" when I start GDB.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

SiegeLord
Member #7,827
October 2006
avatar

Attached is a diff to Allegro source to stick a printf inside the place that first receives Windows keyboard events... also attached is a modified test file from earlier in the thread (also with a corresponding printf). Try running that, I guess, and see if there's an obvious discrepancy between the Windows event and Allegro event arrival times. Additionally, it may show that the delay happens before Windows events even arrive, which limits the number of things that can be done from Allegro's side of things...

Frankly, this seems like a case of the driver implementing vsync via a busy loop that blocks whatever thread generates Windows keyboard events.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

pkrcel
Member #14,001
February 2012

Well, I know for sure that I have different Intel drivers on my laptops (since work's one is Dell and does not allow me to download generic GFX driver from Intel...even thou the chipset is the same), so that seems something very likely (and maybe corrected in a more recent version of the driver?)

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

GullRaDriel
Member #3,861
September 2003
avatar

I am able to reproduce the problem with my build of allegro 5 and the OP code.

Trying to see what I can shotdebug.

Here Winx64 Intel + Ati 5500 , gcc version 4.6.1 (GCC), latest mobility drivers, all up to date.

It's not saying so much so far, even when I play with the code. I'm as you with it for now.

Edit:
Wow, I didn't saw allegro uses a tons of threads / mutexes for a single loop.

All my projects are still linked to a4. There was at least half less threads / locks with it.

In case your curious I spoiled what it looks like in gdb.

C:\Users\Gull\Desktop\test>gdb testbug.exe
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\users\gull\desktop\test\testbug.exe...done.
(gdb) run
Starting program: c:\users\gull\desktop\test\testbug.exe
[New Thread 9648.0x90c]
[New Thread 9648.0x1c48]
[New Thread 9648.0x4e0]
[New Thread 9648.0x1b7c]
[New Thread 9648.0x2280]
[New Thread 9648.0x514]
[New Thread 9648.0x2010]
[New Thread 9648.0x2e8]
[New Thread 9648.0x2018]
[New Thread 9648.0x1b64]
[New Thread 9648.0xd80]
[New Thread 9648.0x868]

Program received signal SIGINT, Interrupt.
[Switching to Thread 9648.0x868]
0x74ec6da7 in NlsUpdateSystemLocale () from C:\Windows\syswow64\kernel32.dll
(gdb) info threads
Id Target Id Frame

  • 12 Thread 9648.0x868 0x74ec6da7 in NlsUpdateSystemLocale ()

from C:\Windows\syswow64\kernel32.dll
11 Thread 9648.0xd80 0x772f1f26 in ntdll!LdrQueryProcessModuleInformation
() from C:\Windows\system32\ntdll.dll
10 Thread 9648.0x1b64 0x772f013d in ntdll!RtlEnableEarlyCriticalSectionEven
Creation () from C:\Windows\system32\ntdll.dll
9 Thread 9648.0x2018 0x772f1f26 in ntdll!LdrQueryProcessModuleInformation
() from C:\Windows\system32\ntdll.dll
8 Thread 9648.0x2e8 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
7 Thread 9648.0x2010 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
6 Thread 9648.0x514 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
5 Thread 9648.0x2280 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
4 Thread 9648.0x1b7c 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
3 Thread 9648.0x4e0 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
2 Thread 9648.0x1c48 0x772ef8b1 in ntdll!RtlUpdateClonedSRWLock ()
from C:\Windows\system32\ntdll.dll
1 Thread 9648.0x90c 0x7690e977 in ScaleViewportExtEx ()
from C:\Windows\syswow64\gdi32.dll
(gdb) t 1
[Switching to thread 1 (Thread 9648.0x90c)]
#0 0x7690e977 in ScaleViewportExtEx () from C:\Windows\syswow64\gdi32.dll
(gdb) bt
#0 0x7690e977 in ScaleViewportExtEx () from C:\Windows\syswow64\gdi32.dll
#1 0x7690e977 in ScaleViewportExtEx () from C:\Windows\syswow64\gdi32.dll
#2 0x739977f6 in ?? () from C:\Windows\SysWOW64\d3d9.dll
#3 0x66986313 in atiu9pag!XopOpenAdapters9 ()
from C:\Windows\SysWOW64\atiu9pag.dll
#4 0x663c79f6 in atiudx!OpenAdapter () from C:\Windows\SysWOW64\atiumdag.dll
#5 0x663c8625 in atiudx!OpenAdapter () from C:\Windows\SysWOW64\atiumdag.dll
#6 0x663cccdd in atiudx!OpenAdapter () from C:\Windows\SysWOW64\atiumdag.dll
#7 0x66984563 in atiu9pag!OpenAdapter ()
from C:\Windows\SysWOW64\atiu9pag.dll
#8 0x73997eff in ?? () from C:\Windows\SysWOW64\d3d9.dll
#9 0x73997641 in ?? () from C:\Windows\SysWOW64\d3d9.dll
#10 0x739da113 in d3d9!D3DPERF_BeginEvent () from C:\Windows\SysWOW64\d3d9.dll
#11 0x739da0a2 in d3d9!D3DPERF_BeginEvent () from C:\Windows\SysWOW64\d3d9.dll
#12 0x6554e53e in d3d_flip_display (al_display=0x6348f0)
at C:\Users\Gull\Downloads\allegro-5.0.8\allegro\src\win\d3d_disp.cpp:1992
#13 0x654d7d60 in al_flip_display ()
at C:\Users\Gull\Downloads\allegro-5.0.8\allegro\src\display.c:142
#14 0x00401631 in main () at testbug.c:100
(gdb)

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Peter Wang
Member #23
April 2000

Allegro 5 does not, itself, use significantly more threads than Allegro 4. I don't know where those are coming from, but they're not ours.

pkrcel
Member #14,001
February 2012

Well then, I newly compiled Allegro with Siegelord's patch, while updating my GFX drivers....and the provided example with printf as well.

I am unable to get again the unresponsive inputs whichever GFX adapter I choose, confirmed by the printf logs:

Win Event: 83 0.631955
Allegro Event 83 0.648214
Win Event: 82 0.732805
Allegro Event 82 0.748350
Win Event: 83 0.833111
Allegro Event 83 0.848606
Win Event: 84 0.850112
Allegro Event 84 0.865288
Win Event: 82 0.951312
Allegro Event 82 0.965720
Win Event: 83 1.050036
Allegro Event 83 1.066165
Win Event: 84 1.099826
Allegro Event 84 1.116000
Win Event: 82 1.132794
Allegro Event 82 1.149312
Win Event: 83 1.316879
Allegro Event 83 1.333064
Win Event: 85 1.333785
Allegro Event 85 1.349995
Win Event: 82 1.416838
Allegro Event 82 1.433294
Win Event: 83 1.600825
Allegro Event 83 1.617229
Win Event: 85 1.617944
Allegro Event 85 1.633851
Win Event: 82 1.717805
Allegro Event 82 1.734039
Win Event: 83 1.818855
Allegro Event 83 1.834302
Win Event: 85 1.834871
Allegro Event 85 1.850994
Win Event: 82 1.952021
Allegro Event 82 1.967972
Win Event: 83 2.051822
Allegro Event 83 2.068397
Win Event: 84 2.135885
Allegro Event 84 2.151752
Win Event: 82 2.369903
Allegro Event 82 2.385716
Win Event: 83 2.469870
Allegro Event 83 2.485830
Win Event: 84 2.552880
Allegro Event 84 2.569364
Win Event: 82 2.587620
Allegro Event 82 2.602811
Win Event: 83 2.836985
Allegro Event 83 2.853360
Win Event: 82 2.853887
Allegro Event 82 2.870102
Win Event: 83 2.920896
Allegro Event 83 2.937080
Win Event: 85 3.070914
Allegro Event 85 3.087349
Win Event: 82 3.121911
Allegro Event 82 3.137384
Win Event: 83 3.222006
Allegro Event 83 3.237620
Win Event: 85 3.238071
Allegro Event 85 3.254403
Win Event: 82 3.306905
Allegro Event 82 3.321270
Win Event: 85 3.405924
Allegro Event 85 3.421426
Win Event: 83 3.471902
Allegro Event 83 3.488242
Win Event: 82 3.521884
Allegro Event 82 3.538340
Win Event: 83 3.706044
Allegro Event 83 3.722122
Win Event: 84 3.723106
Allegro Event 84 3.738826
Win Event: 82 3.873242
Allegro Event 82 3.889200
Win Event: 83 3.906942
Allegro Event 83 3.922599
Win Event: 82 4.207265
Allegro Event 82 4.223381
Win Event: 83 4.290994
Allegro Event 83 4.308944
Win Event: 82 4.425650
Allegro Event 82 4.440520
Win Event: 83 4.592243
Allegro Event 83 4.607661
Win Event: 85 4.608001
Allegro Event 85 4.624279
Win Event: 82 4.742402
Allegro Event 82 4.758023
Win Event: 85 4.859051
Allegro Event 85 4.874878
Win Event: 82 4.942985
Allegro Event 82 4.958534
Win Event: 83 5.108969
Allegro Event 83 5.125586
Win Event: 84 5.125958
Allegro Event 84 5.142174
Win Event: 82 5.243130
Allegro Event 82 5.259198
Win Event: 83 5.292998
Allegro Event 83 5.311233
Win Event: 85 5.494492
Allegro Event 85 5.509707
Win Event: 82 5.509974
Allegro Event 82 5.526480
Win Event: 85 5.577616
Allegro Event 85 5.593233
Win Event: 83 5.594764
Allegro Event 83 5.609959
Win Event: 82 5.710989
Allegro Event 82 5.726949
Win Event: 83 5.828702
Allegro Event 83 5.843872
Win Event: 85 5.845399
Allegro Event 85 5.860559
Win Event: 82 6.012011
Allegro Event 82 6.027609
Win Event: 83 6.129025
Allegro Event 83 6.145101
Win Event: 84 6.196034
Allegro Event 84 6.211404
Win Event: 82 6.361971
Allegro Event 82 6.378481
Win Event: 83 6.580532
Allegro Event 83 6.595614
Win Event: 82 6.697039
Allegro Event 82 6.712635
Win Event: 85 6.713115
Allegro Event 85 6.729426
Win Event: 83 6.730178
Allegro Event 83 6.746063
Win Event: 82 6.980547
Allegro Event 82 6.996772
Win Event: 85 6.997067
Allegro Event 85 7.013363
Win Event: 82 7.081048
Allegro Event 82 7.096853
Win Event: 82 7.265169
Allegro Event 82 7.280588
Win Event: 84 7.348078
Allegro Event 84 7.364206

BUT, the original GaryT example still lags in inputs as before....with some inconsistency...sometimes it just runs okay with both GFX cards, but it's really really rare (I think I tried some 40 times already).

Going to sleep now.... ;D

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

 1   2   3   4 


Go to: