Weird bug when running GUI stuff in Ubuntu 11.04

Archives Forums/Linux Discussion/Weird bug when running GUI stuff in Ubuntu 11.04

AnthonyB (Posted 2011) [#1]

Hi, I have a weird problem. I am running Ubuntu 11.04 on my laptop, and when I build GUI applications, for some reason my applications only respond when I move the mouse inside the window. I compiled the exact same code on Windows and it works without any problems there. This is really annoying because one of my applications is a server that needs to respond quickly. But right now I have to hover the mouse over the server window, moving it all the time, to respond to ANYTHING. It has 0 FPS when the mouse is not moving. It responds from keyboard input as well, but not unless the key is pressed for 0,3-0,5 seconds. It's somehow like it doesn't do anything unless there is some external input streaming into the application. This is really weird. I did not have this problem at all on Ubuntu 10.10. Does anyone have ANY idea? Regards, Anthony

skidracer (Posted 2011) [#2]

Can you please test with the RedrawGadget example code. Are there any signs of problems running MaxIDE itself? Last edited 2011

AnthonyB (Posted 2011) [#3]

What is the "RedrawGadget" example code, and where can I get it? No there are no problems running MaxIDE. Not that I have noticed anyway.

skidracer (Posted 2011) [#4]

Type RedrawGadget into MaxIDE, if it highlights hit F1 twice.

AnthonyB (Posted 2011) [#5]

It doesn't. I think I might have been unclear. I'm not running a MaxGUI app. I am running a GUI app. I mean the app is not a console app. I can understand why you got confused though, if you thought I meant a MaxGUI app, as I wasn't really that clear about it.

BlitzSupport (Posted 2011) [#6]

I haven't encountered this problem myself. Does it happen with the samples, and not just your own stuff? I'm wondering if adding PollSystem or WaitSystem to your main loop might make any difference? If not, can we see some code?

AnthonyB (Posted 2011) [#7]

Adding PollSystem or WaitSystem unfortunately doesn't change much. The actual code is very large. I have been developing this for the past 6 months and it was just when I recently upgraded to Ubuntu 11.04 I experienced any problems. I had the idea that maybe the keyboard input thread in my custom GUI library I use for this isn't working anymore, so I tried just removing the input thread code from the GUI (so that the thread is never launched), and the error disappeared. So I think we found our culprit. But now I cannot enter anything into the application using the keyboard anymore. Is there a better way to handle input? The reason I wrote a thread for the keyboard input is because I have input in the GUI library to the forms etc, and the application has a custom written console that is independent of the GUI library that also needs input. The only way to make them share input was to have a keyboard input thread handling the input. This works fine in Windows, and in earlier Ubuntu versions, but not in Ubuntu 11.04 it seems. EDIT: I should also add that nowhere do I wait for the thread. Here's the code for the input thread: type GUI_InputThread '// ------------------------------------------------------------------------------------------------------------- '// Input thread. '// ------------------------------------------------------------------------------------------------------------- function inputThread:object(arg:object) RabMT.newMutex("__GUI__input_thread"); local inputMutex:TMutex = RabMT.getMutex("__GUI__input_thread"); local curChar:short = 0; while (not m_endInputThread) if (not curChar) .. curChar = getChar(); if (curChar) then if (inputMutex.tryLock()) then m_currentKey = curChar; inputMutex.unlock(); curChar = 0; end if end if end while return null; end function '// ------------------------------------------------------------------------------------------------------------- '// Get the currently pressed key. '// ------------------------------------------------------------------------------------------------------------- function getCurrentKey:short() local inputMutex:TMutex = RabMT.getMutex("__GUI__input_thread"); local key:short = 0; if (inputMutex.tryLock()) key = m_currentKey; m_lastKey = m_currentKey; m_currentKey = 0; inputMutex.unlock(); end if return key; end function '// ------------------------------------------------------------------------------------------------------------- '// Make sure you never create an instance of this class, since it's acting as a namespace. '// ------------------------------------------------------------------------------------------------------------- method new() local id:string = TTypeId.forObject(self).name() runtimeError("Illegal to create an instance of a namespace class '" + id + "'.") end method '// ------------------------------------------------------------------------------------------------------------- '// Current key, set by the input thread. '// ------------------------------------------------------------------------------------------------------------- global m_currentKey:short = 0; '// ------------------------------------------------------------------------------------------------------------- '// Last pressed key. '// ------------------------------------------------------------------------------------------------------------- global m_lastKey:short = 0; '// ------------------------------------------------------------------------------------------------------------- '// Set to true to end the input thread. '// ------------------------------------------------------------------------------------------------------------- global m_endInputThread:byte = false; end type Yet another edit: I know I end statements with ';' etc. That is just because I love the way it looks. I know I don't have to do it. And I also program alot in C++, so the ';' help me not forget to add that when programming in that language. ;) Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011

BlitzSupport (Posted 2011) [#8]

Hmm, not sure I can really help with that setup (and not really knowing much about how the rest of the program works), but this thread, although not quite the same situation, suggests that event polling isn't enabled unless you call Graphics, so if you're creating your display 'manually' via CreateGraphics/SetGraphics that might be relevant. There's also a PollEvent command (and PeekEvent), which might allow the app to process/clear its event queue if it's not polling for events but just waiting for them to come in (which it sounds like it's doing, ie. it updates when it receives mouse events). Lastly, there's a 'hidden' EnablePolledInput command, and adding that before the loop in Gfk's example (in the above thread) 'fixes' it, so maybe give that a go. (I'm not too clued in on low-level event-handling in any kind of depth, though, sorry.)

BlitzSupport (Posted 2011) [#9]

See this thread, and the last post in particular, too... seems relevant to me anyway.

AnthonyB (Posted 2011) [#10]

None of that helped, unfortunately. :/ I think there could be something wrong with how Ubuntu handles threads now? I mean when doing it with the BRL module. Compatibility issues. Because what those two threads suggested didn't work, and I am using AppTerminate() in the while loop that I use as my main loop, so I know the system is polled each frame. I also tried putting polledsystem in the input loop and after the flip command, but nothing works.

AnthonyB (Posted 2011) [#11]

After alot of digging I noticed that this only commands like cls, flip, drawtext, drawrect, drawline etc together with the input thread causes this problem to arise. If I remove all of these commands, the application is never suspended. I created this little test program to simulate the conditions of the original program as closely as possible, but making it easier for you guys to understand and read: import "../Games/GoL/lib/GUI/GUI.bmx" superstrict setgraphicsdriver(glmax2ddriver()); graphics(800, 600, 0, 60, 0); setMaskColor(0, 0, 0); setColor(255, 255, 255); setBlend(ALPHABLEND); setClsColor(0, 0, 0); global font:TImageFont = loadimagefont("Arial.ttf", 12); setImageFont(font); type ThreadClass function thread:object(data:object) while (not shutdown) delay(1); print("1: " + index); index :+ 1; if (index > 500) .. index = 0; end while end function function thread2:object(data:object) while (not shutdown) delay(1); print("2: " + index3); index3 :+ 1; if (index3 > 500) .. index3 = 0; end while end function global index:int = 1; global index3:int = 1; global shutdown:byte = false; end type global index:int = 0; local myThread:TThread = CreateThread(ThreadClass.thread, null); sGUI.init(800, 600); while (1) cls(); delay(1); drawtext("Here I am!", index, 12); print("Here I am!"); index :+ 1; if (index > 500) .. index = 0; flip(); end while ThreadClass.shutdown = true; waitthread(myThread); The GUI input thread is launched in the sGUI.init() function. When I comment out cls, drawtext and flip, it works flawlessly. When I comment out cls and drawtext, but leave flip untouched, I see "Here I Am" fewer times, but it still happens. It doesn't matter if I move the mouse over the window or not. When I comment out cls and flip or drawtext and flip, I only need to get the mouse over the window and then it starts working flawlessly like when all three commands are commented out. When I comment out only cls or drawtext, so that one of them is untouched as well as flip, then it works like in my original post. I have to move the mouse over the window continuously for the main program to respond. So it seems that the drawing commands and the getChar command when in a thread (like I do in the GUI input thread) has something to do with the problem I am experiencing. Maybe they have something in common? And maybe that part is not thread safe? Does anyone know? Regards, Anthony Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011

skidracer (Posted 2011) [#12]

Max2D under OpenGL is not thread safe so you can only expect it to work from your base thread.

AnthonyB (Posted 2011) [#13]

Yes but I only use Max2D in my main thread. It's polled input together with max2d that seems to create difficulties. I use polled input in the input thread (getChar()). Last edited 2011

AnthonyB (Posted 2011) [#14]

Here's a new version that you can try yourself, that produces the same problem on my system, that I am experiencing with my original program. It includes the input thread from my GUI library and everything. Run this in Ubuntu 11.04 if you can, and see if you experience the same problem? superstrict setgraphicsdriver(glmax2ddriver()); graphics(800, 600, 0, 60, 0); setMaskColor(0, 0, 0); setColor(255, 255, 255); setBlend(ALPHABLEND); setClsColor(0, 0, 0); type GUI_InputThread '// ------------------------------------------------------------------------------------------------------------- '// Input thread. '// ------------------------------------------------------------------------------------------------------------- function inputThread:object(arg:object) local curChar:short = 0; while (not m_endInputThread) if (not curChar) .. curChar = getChar(); if (curChar) then if (inputMutex.tryLock()) then m_currentKey = curChar; inputMutex.unlock(); curChar = 0; end if end if end while return null; end function '// ------------------------------------------------------------------------------------------------------------- '// Get the currently pressed key. '// ------------------------------------------------------------------------------------------------------------- function getCurrentKey:short() local key:short = 0; if (inputMutex.tryLock()) key = m_currentKey; m_lastKey = m_currentKey; m_currentKey = 0; inputMutex.unlock(); end if return key; end function '// ------------------------------------------------------------------------------------------------------------- '// Current key, set by the input thread. '// ------------------------------------------------------------------------------------------------------------- global m_currentKey:short = 0; '// ------------------------------------------------------------------------------------------------------------- '// Last pressed key. '// ------------------------------------------------------------------------------------------------------------- global m_lastKey:short = 0; '// ------------------------------------------------------------------------------------------------------------- '// Set to true to end the input thread. '// ------------------------------------------------------------------------------------------------------------- global m_endInputThread:byte = false; '// ------------------------------------------------------------------------------------------------------------- '// Input thread mutex. '// ------------------------------------------------------------------------------------------------------------- global inputMutex:TMutex = createMutex(); end type global index:int = 0; local inputThread:TThread = CreateThread(GUI_InputThread.inputThread, null); createThread(GUI_InputThread.inputThread, null) while (not appterminate()) cls(); delay(1); drawtext("Here I am!", index, 0); print("Here I am!"); index :+ 1; if (index > 500) .. index = 0; flip(); end while GUI_InputThread.m_endInputThread = true; waitthread(inputThread); EDIT: Updated the code so that you don't need a custom font to run it. Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011 Last edited 2011

skidracer (Posted 2011) [#15]

I don't understand your motives. Multithreading wasn't designed so that you could call functions like GetChar 1 billion times per second, even if they were documented as being Thread Friendly, which they are not.

AnthonyB (Posted 2011) [#16]

As I said previously in this topic, my GUI library has to have input, or else you wouldn't be able to input text to forms etc. And my program, that uses this GUI library, has a console, that doesn't use the GUI library at all. This console also needs to have keyboard input. Well, if I just put getChar in both places (meaning in the same frame), then one of them gets regular input, and the other one gets like 1/4th of the inputs. I would think that means that calling getChar() flushes the keyboard input buffer. So the only way to make them both be able to receive input would be for them to share the input. Alright, so if I do that, I still call getChar() twice, since both need to access the currently pressed key at the same frame, and nothing changes. If I store the value once each frame, and the next time I call it it just sends that same value as before, without calling getChar() twice. That should solve the problem, yes? Well I still receive the same problem. This means that my only option is leaving it in a thread, and not accessing it's value directly, but the value of the variable where I store the last known value, thus accessing it indirectly. That worked. And it still works flawlessly in Windows, and in earlier Ubuntu versions. But as soon as I update to Ubuntu 11.04, it stopped working.