linux C++ xlib, does the processor go to fast? - c++

here something sound like tricky for me, actualy i'm using Xlib to draw some windows. One is for plotting some 2D results in a image, so this one is drawn only when all calculus are done. another one is a simple window wich says, "calculus in process".
So now before I start the calculus I call "show me the simple window "calculus in process"",
then I call the function who does the calculs and plots the result,
then I call "don't show me the simple window "calculus in process"".
but the problem ams, I don't see the "show me the simple window "calculus in process"" during the calculus, I just see it one instant and disappears just when the image of results of calculs is shown. I try to put some sleep() but that doesn't solve the problem. What kind of stuff can cause such problem ? I already met such problem during my C++ course, at that time I worked on console, I never found the reason of such problem.
Can somebody give me some explanation and tips to help me to deal with it like a boss ?
here a piece of sh.. of my code :
switch(e.type/*xlibevent*/){
.
.
.
case KeyRelease :
switch(keyRelease()){ // keyRelease just recognize wich key was released
.
.
. // w3w1 = window "calculus in process"
case 3 : w3w1.switcher(); doCalculus(&w1); w3w1.switcher(); break;
.
.
.
.
.
.
}
I just did a test, I swap doCalculus(&w1) with sleep(3) same result, I don't see my window "calculus in process"
there is the switcher() corrected
void switcher(){
if(this->visible==0){
XMapWindow(dpy,this->window); // what I though before : has to map the window
// what I think now : request to map the window
XDrawString(dpy, this->window, this->gc, 10, 14, text.c_str(), text.length());
XFlush(dpy); // dats what missed, not sure that efficient to flush the dpy
// but I deal with the part of xlib I know, I will check further
// about that
visible=1;
}else{
XUnmapWindow(dpy,this->window);
XFlush(dpy); //...
visible=0;
}

Your main event loop is probably blocked by your calculation. Thus nothing can be displayed as long as you are busy computing. If you return to the X event loop at least once after displaying the temporary window it should appear (though it may not refresh properly because it won't respond to exposure events). The best solution is to run your calculations in another thread.
Your confusion about "why it doesn't wait to show me the simple window" is based on a misconception about how X clients work. There is more interaction between the client and the server (even to do simple things) than you might intuitively expect.

I know that this isn't an OpenGL question, but this OpenGL tutorial can shed some light into this issue. Basically, you're not processing the 'windows' messages to allow for the window you've created to show up. Check the while(1) loop in the wiki.
You have two choices:
Run your calculation in steps. Where each step gets processed by each call within the while loop
Run your calculation in a separate thread, query for progress in every frame from within the while(1) loop and display it.
Personally, I'd prefer 2.

Related

Windows C++ 32-bit DLL Strange Behavior in Timer Thread

I am just learning how to right a DLL. This project will ultimately be a plugin for music players and is based on Winamp 5.X.
I want to create a window to show information about the playing song that updates periodically, but it's not a "visualization" plugin which is by definition called back repeatedly by the main program. I need a timer, and another source suggested to use CreateTimerQueueTimer() which starts a separate thread to receive the timeout event instead of infinite looping and checking window messages for stop condition. I have no knowledge of multithreading architecture (if any) in the main program so I similarly don't want to just loop through a "sleep" interval then refreshing output.
The approach seems to work. It is based on a callback function:
char message[12] = "Hallo World";
VOID CALLBACK TimerCallback(PVOID lpParameter, BOOLEAN reserved)
{
message[1] += 1;
MessageBoxA(NULL, message, "Dummy", MB_OK);
}
The 1st popup shows "Hallo World", the 2nd "Hbllo World" on so on.
The mystery is that when I switch the two lines of code in the CALLBACK, all the popups (which are created every 10 seconds) show "Hallo World". I don't understand why that is happening, and I don't think I should try to move on to more complex tasks until I get what's going on here.
As always, any help is greatly appreciated.
Okay, I kind of figured this out. Thought it might help someone else to leave the post up.
In previous testing, I was not closing the popup MessageBox before a new one was generated. On further testing, when I close the boxes as they appear, both behaviors increment as expected.
Still, if anyone wants to comment I'm not completely at ease with my understanding of whats happening.

Qt C++ preventing program to show error-messages when busy

Hi I have a question concerning error-messages.
I have a window with several buttons including a OK and Cancel-button. My OK-button executes a program that moves some chart series and for doing so it needs to read in lots of data from a file and shift these values. The Cancel button cancels this operation. The calculations cannot be separated into smaller portions of code.
This works well for smaller amount of data but when I use it with large sets of data the program acts as if it crashed. Nevertheless, after some time everything is back to normal, the calculation is done.
There are 2 things I don`t like:
1) When I leave the program alone the program changes the headerline of my window to ....(keine Rückmeldung) which means no response.
After the end of the calculation the text ...(keine Rückmeldung) disappears in the header and everything is back to normal.
2) When I try to press the "cancel" button in my window while running the calculation, an additional window appears:
There again, when I leave the program alone and the calculation is finished this window disappears ( as well as the (keine Rückmeldung) in the header of my window) and and everything is back to normal.
To solve problem 2 I tried to disable my "Cancel" button but this does not help. The slot which is behnid the cancel-button gets executed anyway.
My question now is: Since I don´t want the user to see these error-messages, is there a way to prevent the program of showing them?
Thank you
Consider using a QThread for expensive computation tasks. Or better, you can use other built-in multi-threading utilities such as QConcurrentRun and QFuture.
You can then easily get the state of your background function and show a loading Window, or allow the user to perform other operations in the meantime.

How do you fix a program from freezing when you move the window in SDL2?

I'm making a small game with a friend and one problem is that when you drag the window around, it freezes and the program completely stops until you let go. I searched for a simple solution but I only found out that it happens with everything. Also, it screws up the delta time since it acts like a really long frame. Is there any way to either simply have the program continue running while you move it or if that's too complicated, fix the delta time? Thanks?
Your application is most likely "freezing" because it has a WinMain loop similar to this:
while (true)
{
if(PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
TickGame();
}
}
So instead of ticking it is processing the WM_MOVE message . One simple work around would be just to call your games tick function within the move message, or perhaps it makes sense to pause the game when you get the first move message and unpause it if you haven't gotten one for a second or two. That is, are people really going to be dragging the window WHILE playing, unlikely.
To answer your second question, typically games (physics engines especially) will use a fixed time step to stabilize the simulation, read more about fixed time step here.

wxWidgets - cannot bring frame to top

EDIT:
This question isn't about briging a window to the front of EVERYTHING, just for my specifc application. I'd like the frame they were interacting with to be behind the new frame. Much like a dialog, except that it is not a dialog. I don't think this is bad practice, something was summoned (in this case via a menu) I expect it to be infront of the window I used to summon it.
I just read How can I ensure that a wxFrame is brought to the foreground? and that didn't work either.
SetFocus(); makes the window want my attention (it flashes in my task bar in the case of my platform, GTK and MATE task bar if that matters)
Raise(); does.... nothing
Show(); shows it, obviously, but despite it's newly created status nothing happens.
Weirdly clicking the window doesn't bring it to the front until after I have done something in the parent despite showing as the thing I am interacting with in the task bar. I am using all the 3 of the above (Show, SetFocus then Raise).
I've read Raise's documentation ( http://docs.wxwidgets.org/trunk/classwx_window.html#a54808c933f22a891c5db646f6209fa4d ) Raise and Lower are "z-order functions" - this suggests that it's supposed to do this. I have never really had much success with it though. I'd be really really nice if the starting frame came to the foreground whenever I run for example, but given the amount of times I press run and the project is built compared to the amount of time spent writing code and the fact creating a new folder even is more frequent, I've put up with it.
It'd be nice to get it fixed!
Addendum
Using Lower on the parent hasn't worked. There will be 64 less a few obvious ways to try this, I really want to avoid stumbling about.
I believe ravenspoint, and this is not a good user interface trick, but, if you don't mind a little bit of flashing... and stealing of focus, regardless of where you may be typing, etc, etc, just kinda bad...
ParentWindow->Iconize(false); // restore the window if minimized
ParentWindow->SetFocus(); // focus on my window
ParentWindow->Raise(); // bring window to front
ParentWindow->Show(true); // show the window
And before you do, think about another critical application running with
"Enter the counter measure launch code, impact in 12 seconds: "
and half way through typing, your window decides to pop to the top.

How to make a loading/intro animation popup while waiting for program to start up clutter/GTK+

My program takes a few seconds to start up. I am using clutter for the GUI, and I decided to try and make something pop up to indicate that the program is starting up. I wanted to just have a logo pop up and rotate, then disappear when the program starts.
So in clutter, I figured I could just make a new stage (window) add an actor to it, make the and actor spin, in the first section of the main function. The window will pop up right away, but with no content, but the content wont show until you launch the clutter main loop.
So I was just wondering how I might be able to achieve this using clutter or GTK+.
If you are familar with reaper 4, the audio recording program, this program does something similar to what I want to mine to do.
What you want is called a splash screen. I'm unfamiliar with clutter, but I found this GTK splash screen example.
However, I think you're taking the problem the wrong way. Splash screens are a bad idea because you just add overhead. What you need is improving your startup performance, by doing some CPU and/or IO profiling. Loading stuff on-demand, and not all at once will help.
Unfortunately I'm unfamiliar with Clutter. But I'm pretty sure it will be difficult to render an animation without a main loop running in any high level library.
I'd try to put the code that causes the delay into a separate thread and inform the main loop when the startup is done.
Something like this is what i use:
string splashfile = path_templ + "/splashimg.png";
GtkWidget *image=gtk_image_new_from_file(splashfile.c_str());
gtk_container_add(GTK_CONTAINER(SplashWindow), image);
gtk_widget_show_all(SplashWindow);
//Cycle through all iterations (refresh everything in the GUI)
while (gtk_events_pending()){
gtk_main_iteration();
}
sleep(1);
(... rest of code ...)
gtk_main ();
gdk_threads_leave ();
Especially that last part of while events pending is the key