Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Daniel K. O. <dan...@ya...>]

Michael C Urban wrote:

>Updating the GUI in the main thread can cause noticable delays in the user
>interface. The progress bar is a good example. If you update that from the
>main thread, then every time the main thread has to repaint the progress
>dialog, it's going to interrupt the user experience.
>  
>


I don't think repainting the progress bar could take more time than 
painting a label... the idea isn't to make all the job in the main 
thread, just use a function that receives one arg, and call something like:

---
gboolean my_idle_callback_that_updates_the_progress_bar()
{
    gdk_threads_enter(); /* idle funcs run outside the lock */

    /* my_val is set in the other thread, inside 
gdk_threads_enter()/leave(),
    so the gui is not updated ouside the main thread, no problem at all.
     Now the idle func just have to retrieve the value, and use it properly.
 */
    float pb =  (float)g_object_get_data(G_OBJECT(my_progress_bar), 
"my_val");  
   
    gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(my_progress_bar), pb);

    if (pb>0.99) { /* are we finished? lets make the GUI sensitive again */
       gtk_widget_set_sensitive(toplevel_window, TRUE);

       /* here we could also change some texts, show a message window, 
play some sound, etc */
    }
  
    gdk_threads_leave();
    return FALSE; /* run this idle func just once */
}
---


The idle funcs have low priority by default, your thread could call 
gtk_idle_add a million times, and if the GUI is still busy with other 
things, the idle funcs will wait. Then they all will run; or you can 
just change their priority, calling gtk_idle_add_full, giving them more 
priority, for example, depeinding what you want. I don't think you can 
freely define this behavior in a log of GUI toolkits.


>Animation and VR simulations that require rapid repainting of the display
>are another area where you often don't want to tie up the main thread by
>forcing it to handle the paint requests and such. The application can
>become extremely unresponsive if the main thread has to handle such paint
>intensive tasks.
>

Yeah, this really seems a problem.
But GTK+ isn't intended for intensive repainting, like VR and 
Animations. You can use something like GtkGLExt, or GtkSDL, or something 
else, and plug this extra widget into your application. To manipulate 
their content you won't need to use Gtk+ API calls, you'll use 
SDL_BlitSurface, glVertex, etc. They should work fine when running from 
another thread.



Daniel K. O.