Re: eog slowdowns, glib question

[Emmanuel Touzery <emmanuel touzery free fr>]

Hello,
> the time).
> >
> >       I've put debug statements in the code and the problem seems to
> >  occur between those two locations:
> >
> >  eog-job-queue.c in handle_job():
> >
> >       g_idle_add_full (G_PRIORITY_DEFAULT_IDLE,
> >                (GSourceFunc) notify_finished,
> >                job,
> >                g_object_unref);
> >  ...
> >       So it seems probably the main loop is busy I guess.
>
> It would be interesting to know what the mainloop is busy with. Not sure
> how to that in a nice way. Maybe it's possible to see where in the code
> it is when you break at the above g_idle_add and make a thread
> backtrace.
>
>    
Firstable it appears also with metacity.
Then here is what GDB says if I Ctrl-C when i get the slowdown:

(gdb) info thread
  2 Thread 0xb69f8b90 (LWP 6751)  0xb7f05430 in __kernel_vsyscall ()
* 1 Thread 0xb6bda750 (LWP 6748)  0xb77c8e66 in ?? ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0

#0  0xb77c8e66 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#1  0xb77c9252 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#2  0xb77c2a28 in gdk_pixbuf_scale () from /usr/lib/libgdk_pixbuf-2.0.so.0
#3  0xb6a5d3f6 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#4  0xb6a5e504 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#5  0xb6a5ae07 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#6  0xb6a5be85 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#7  0xb7a0fece in gtk_paint_box () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb79cbf90 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb79cc2d6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7994526 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb75463d9 in ?? () from /usr/lib/libgobject-2.0.so.0
#12 0xb7547c7b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb755daff in ?? () from /usr/lib/libgobject-2.0.so.0
#14 0xb755f34f in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#15 0xb755f936 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#16 0xb7aaf2ae in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb798e56d in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb7802e95 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#19 0xb78034af in gdk_window_process_all_updates ()
   from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb78034db in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#21 0xb77e68fb in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#22 0xb74bcc81 in ?? () from /usr/lib/libglib-2.0.so.0
#23 0xb74beb88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#24 0xb74c20eb in ?? () from /usr/lib/libglib-2.0.so.0
#25 0xb74c25ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#26 0xb798e7d9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x08061a71 in main ()

so, gdk_window_process_all_updates() and specifically 
gdk_pixbuf_scale(). Here is what the mainloop is doing.

And the other thread (the one which should load the pixbuf I guess):

#0  0xb7f05430 in __kernel_vsyscall ()
#1  0xb7c8d0e5 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x08087dea in ?? ()
#3  0xb74e97bf in ?? () from /usr/lib/libglib-2.0.so.0
#4  0xb7c894ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb729349e in clone () from /lib/tls/i686/cmov/libc.so.6

I guess waiting to sync with the mainloop.

Is it possible.. that all of this is because I clicked or moved with the 
keyboard on the little icon in the catalog, and that little icon must be 
redisplayed with the selection around it, and it's scaling the full 
10mpx picture to redisplay that little icon? wild theory here, I didn't 
look at the code at all for now. Unless he's calculating in advance new 
pictures to be added to the list of thumbnails in the catalog... In any 
case it shouldn't need to redraw the main picture currently being 
displayed since nothing about it changed.

> >       I tried to change the G_PRIORITY_DEFAULT_IDLE to
> >  G_PRIORITY_HIGH_IDLE and other priorities but then I'm getting warnings
> >  on the command-line (at runtime) and sometimes EOG freezes at startup
> >  (why!?).
> >
>
> On a quick test I can see at least the progress reporting for the jobs
> making problems here. As it is then scheduled behind the finished
> handler (having HIGH_IDLE) it could be called without the job being
> existant anymore (most likely missing ref counting on our side). There
> could be more idle handlers making problems with this.
>    
Very good point. I would need quite some time before I would start 
thinking about that one ;-)
> >       Anyway those slowdowns are a bit annoying for me
> >  (athlon2600+/512Mb/10mpx pictures), I was wondering if you think there's
> >  something that can be done about them (I can try to code a solution
> >  maybe if you give me tips). Maybe stop the other tasks in the main loop
> >  to allow this loading to be done? But that would amount to increasing
> >  the priority, I don't understand why that doesn't work well.
> >
>
> The image loading should be finished at this time already (the job has
> finished running when the code reaches the above g_idle_add()), and is
> not done by the mainloop anyway (all the jobs going through the job
> queue are executed independently from the mainloop). The idle handler
> that is registered here is for emitting a finished signal from the job
> on which the UI starts updating the view.
>
> There's a few things to try. Try running without Compiz if possible.
>    
So that didn't help. Well maybe the problem occurs less often, it's very 
hard to measure. But it 100% still occurs (this backtrace was fetched 
when running metacity).
> Check which plugins are enabled and if it is reproducable without them.
> I think the statusbar-date plugin for example might have some potential
> to block your mainloop.
>
> Felix
>
> P.S. Sorry, for the ugly quoting.
>    
Ah yes, plugins. Yes, it also occurs without plugins. Did a second run 
now just to make sure (I'm running my exif-display plugin otherwise), 
same stacks for both threads.
I can get a different stack for the second thread if I control-C a bit 
faster when it loads pictures slowly (it can be seen quite early because 
the scrollbar doesn't appear), it doing IO to load the pictures or 
JPEG_scanline to parse the picture. But the main loop is always doing 
gdk_window_process_all_updates () and gdk_pixbuf_scale ().

I'll keep looking on my own but any hints are welcome! I'll probably 
never get anywhere on my own.

Thanks!

emmanuel