Re: eog slowdowns, glib question

Am Sonntag, den 31.05.2009, 20:46 +0200 schrieb Emmanuel Touzery:
> Hello,

>      I've noticed some slowdowns in EOG when switching pictures (I'm 
> using the image catalog at the bottom of the window). 
>  ...
> sometimes (one time on 5 or 10) after the choosing the picture the 
> progress bar appears but doesn't move and it takes quite some time for 
> the picture to appear (enough to make compiz decide to change the eog 
> window to black & white most of 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

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

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


P.S. Sorry, for the ugly quoting.

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