Re: eog slowdowns, glib question



Am Mittwoch, den 17.06.2009, 21:36 +0200 schrieb Emmanuel Touzery:
> Hello,
Hi!

> 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

What gtk theme do you use? libpixmap.so is the pixbuf theme engine which
uses pixbufs for the ui elements. If you haven't already please try a
Clearlooks-based theme.

> 
> 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.
> 

It looks more like it's waiting for new jobs to enter the job queue.
The image is likely already loaded as you say you can see libjpeg in the
call stack when you interrupt earlier.

> 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 can't imagine it is the thumbnail generation. eog only loads the
thumbnails for the images that are visible in the collection at the
moment. It could however be the status change for the selected image due
to the theme engine from above. But there are several boxy widgets
around, so...
But it's probably not redrawing the main image, as that doesn't involve
gtk_paint_box (actually the only case where we draw a box on our own is
the message area).

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

Well, I would install debug (or debuginfo depending on your distro)
packages for gtk+, gdk-pixbuf, glib and possibly eog and then retrace.
This might give you the exact line numbers in the trace and should at
least fill the gaps in your traces and hopefully include a few hints on
which widget is repainting at that moment.

Regards,

Felix




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]