Re: Gdk PixbufAnimation supported formats

[Kip Warner]

On Thu, 2013-04-18 at 02:08 -0700, Andrew Potter wrote:
> You can make a few png or jpg frames and hook up a g_timeout_add() callback
> to set the pixbuf on a GtkImage. I done similar when I needed to dynamically
> scale animated gifs. Be sure to stop your timeout on unmap()/unrealize(),
> especially if you have more than a handful of animated images instantiated
> anywhere.

Thanks Andrew. Advice well taken and I'll be sure to consider giving
that a try.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Updating GUI during long operation

[Kip Warner]

On Sat, 2013-04-20 at 23:35 +0100, Chris Vine wrote:
> If you have a main loop running, this is completely unnecessary, unless
> you are doing something to block the loop, which you shouldn't do.

Hey Chris. Although your response was not particularly constructive,
I'll give you the benefit of the doubt. Perhaps I am doing something
unnecessary to block the loop which I should not do. Take a look at the
method defined at 287:

  

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Updating GUI during long operation

[Chris Vine]

On Sat, 20 Apr 2013 09:10:11 -0700
Kip Warner  wrote:

> Hey list,
> 
> I have a separate thread from the main loop that performs some long
> and resource intensive operation. The GUI displays an animated GIF
> while this process takes place via Gdk.PixbufAnimation. 
> 
> Sometimes the animation and the rest of the GUI is very slow to
> repaint and respond to other event messages. What is the best way of
> giving the message pipeline a breather every now and then from
> outside of the main thread?
> 
> I was using GObject.idle_add(self._updateGUI, ...) within the worker
> thread to specify a function to be called regularly that could provide
> some other GUI related update tasks, including the following within
> it...
> 
> # Pump the Gtk+ event handler...
> while Gtk.events_pending():
> Gtk.main_iteration()
> 
> However, my application will crash if I do this with a stack overflow
> within updateGUI. I'm assuming that since idle_add posted the message
> to call the updateGUI callback, when the callback is invoked and
> tries to pump the message pipeline, the method is invoked again
> because it still hasn't cleared itself from the queue.
> 
> I could have tried this aforementioned event pump from outside the
> updateGUI callback and done it from within the worker thread, but I
> didn't know if that was thread safe to do.

If you have a main loop running, this is completely unnecessary, unless
you are doing something to block the loop, which you shouldn't do.

Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Updating GUI during long operation

[Colomban Wendling]

Hi,

Le 20/04/2013 18:10, Kip Warner a écrit :
> Hey list,
> 
> I have a separate thread from the main loop that performs some long and
> resource intensive operation. The GUI displays an animated GIF while
> this process takes place via Gdk.PixbufAnimation. 
> 
> Sometimes the animation and the rest of the GUI is very slow to repaint
> and respond to other event messages. What is the best way of giving the
> message pipeline a breather every now and then from outside of the main
> thread?

Just never do something time consuming in the main loop thread.  If you
don't there should not be any lag.  And to communicate with the main
loop from another thread, the common technique is to add an idle handler
(that runs only once).  The GLib main loop is thread safe so you can
simply call g_idle_add() from the worker thread.

> I was using GObject.idle_add(self._updateGUI, ...) within the worker
> thread to specify a function to be called regularly that could provide
> some other GUI related update tasks, including the following within
> it...
> 
> # Pump the Gtk+ event handler...
> while Gtk.events_pending():
> Gtk.main_iteration()

That's a bad idea.  Forcing flush of pending events never is a real
solution, since at most it will perform everything that was queued, but
certainly not what will come.  And as you see yourself, it doesn't work
that well anyway.

> However, my application will crash if I do this with a stack overflow
> within updateGUI. I'm assuming that since idle_add posted the message to
> call the updateGUI callback, when the callback is invoked and tries to
> pump the message pipeline, the method is invoked again because it still
> hasn't cleared itself from the queue.

That's weird, but yeah, since main_iteration() tells the main loop to
perform an iteration and you do this from an idle event I could imagine
your idle event calls itself recursively.  Again, just never use this
"workaround" method of forcing main loop iterations.

> I could have tried this aforementioned event pump from outside the
> updateGUI callback and done it from within the worker thread, but I
> didn't know if that was thread safe to do.

I think the main loop is completely thread safe, event with this, but
again *do not do this*.  If the even loop freezes, it's that you do too
much work in it's thread, nothing else.  Check what you do in the main
thread and that takes time, and try either optimizing it or movie it to
another thread.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Updating GUI during long operation

[Kip Warner]

Hey list,

I have a separate thread from the main loop that performs some long and
resource intensive operation. The GUI displays an animated GIF while
this process takes place via Gdk.PixbufAnimation. 

Sometimes the animation and the rest of the GUI is very slow to repaint
and respond to other event messages. What is the best way of giving the
message pipeline a breather every now and then from outside of the main
thread?

I was using GObject.idle_add(self._updateGUI, ...) within the worker
thread to specify a function to be called regularly that could provide
some other GUI related update tasks, including the following within
it...

# Pump the Gtk+ event handler...
while Gtk.events_pending():
Gtk.main_iteration()

However, my application will crash if I do this with a stack overflow
within updateGUI. I'm assuming that since idle_add posted the message to
call the updateGUI callback, when the callback is invoked and tries to
pump the message pipeline, the method is invoked again because it still
hasn't cleared itself from the queue.

I could have tried this aforementioned event pump from outside the
updateGUI callback and done it from within the worker thread, but I
didn't know if that was thread safe to do.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list