|
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 |
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 |
SiegeLord
Member #7,827
October 2006
|
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 |
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.... It is unlikely that Google shares your distaste for capitalism. - Derezo |
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 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
|
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. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Thomas Fjellstrom
Member #476
June 2000
|
Edgar Reynaldo said: 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. -- |
Edgar Reynaldo
Major Reynaldo
May 2007
|
@Thomas - if that was the case, where to even look for it? My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Arthur Kalliokoski
Second in Command
February 2005
|
Edgar Reynaldo said: @Thomas - if that was the case, where to even look for it? 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? Edgar Reynaldo said: 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 |
Edgar Reynaldo
Major Reynaldo
May 2007
|
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. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
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 |
GullRaDriel
Member #3,861
September 2003
|
Nobody ever passed this through gdb / dbx / whatsoever debugger ? "Code is like shit - it only smells if it is not yours" |
pkrcel
Member #14,001
February 2012
|
Define "this" It is unlikely that Google shares your distaste for capitalism. - Derezo |
SiegeLord
Member #7,827
October 2006
|
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 |
GullRaDriel
Member #3,861
September 2003
|
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" |
Edgar Reynaldo
Major Reynaldo
May 2007
|
I don't know what I would do with the debugger - it doesn't crash and I don't know what to inspect. Specs - Vista, ATI Radeon X1270 (built in) My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
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. GullRaDriel said: 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 |
GullRaDriel
Member #3,861
September 2003
|
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" |
SiegeLord
Member #7,827
October 2006
|
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 |
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 |
GullRaDriel
Member #3,861
September 2003
|
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: 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 Program received signal SIGINT, Interrupt.
from C:\Windows\syswow64\kernel32.dll
"Code is like shit - it only smells if it is not yours" |
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.... It is unlikely that Google shares your distaste for capitalism. - Derezo |
|
|