Hello Vladimir,

Vladimir Zhbanov schreef op zo 13-09-2015 om 19:26 [+0000]:
> Hi, Richard.
>  
> Could you please check the following two things:
> 
> 1) Open gschem in a terminal (say, xterm or some other) and check, if any
> errors/messages are written when such a situation happens. 

When starting gschem from a terminal and triggering the bug, I don't get
any error messages anywhere. I monitored tail -f for
/var/log/syslog
/var/log/Xorg.log.0
~/.xsession-errors

I also restored the non-proprietary driver xserver-xorg-video-nouveau
instead of nvidia-346.82-0ubuntu0.2 and rebooted, but that didn't change
anything. So I think it is safe to conclude that it is not a graphics
driver issue.


However, I did see something out of the ordinary with good old top: 
When starting gschem with both the status bar and the side bar visible,
but with simply a blank title block, both gschem itself and Xorg gobble
up a HUGE amount of CPU -- each process takes 60% of a CPU core, so
gschem takes a whopping 30% of my 4-core Intel Core i5-3350P 3.10GHz
CPU. And this without doing anything at all. (Memory usage is completely
normal.)

As soon as I close either the status bar (V S) OR the sidebar (V A), CPU
usage returns to normal (i.e. a fraction of a percent).

Then there's a weird thing: when I close and then restore the sidebar 
(2 x V A, without doing anything else in between), the CPU load shoots
up again.
However, when I close and restore the status bar (2 x V S), the CPU load
does NOT go back up right away, but it does go up again after I drag the
main window around by its title bar above a certain speed (very slow
dragging does not cause high CPU usage). I think this too points in the
direction of some sort of (critical race?) issue when redrawing the main
window. Then again, if no-one else is experiencing this bug, there may
of course be an issue with my graphics card (nVidia GeForce GT 640),
although I can't see anything wrong in the log files.


Please note that all this is happening before triggering the 'main
window resize bug'; during all this, the window redraw bug is not yet
triggered, and gschem stays responsive, albeit somewhat sluggish during
the high CPU load condition.


AFTER triggering the main window redraw bug, the situation is different:
CPU load is low, but now the main window is only redrawn after clicking
and rolling the mouse wheel in the main viewport, as described in my
first bug report. As already explained, this behaviour can be stopped by
temporarily closing either the sidebar or the status bar.

So summarizing the observed behaviour in a short list; note that these
are the only actions performed, and in this order (I did not do anything
in gschem itself except showing and hiding the sidebar and status bar,
using the shortcut keys exclusively):

Action				CPU load	Redraw bug
----------------------------------------------------------
1.  start gschem		High		No
2.  sidebar off			Low		No
3.  sidebar on			High		No
4.  status bar off		Low		No
5.  status bar on		Low		No
6.  drag main window (slow)	Low		No
7.  drag main window (fast)	High		No

8.  resize main window		Low		Yes
9.  click/scroll main viewport	Low		Yes (still)
9.  sidebar or status bar off	Low		No
10. either bar on -> goto 2/4	High		No

> 2) Make sure the issue is related to right sidebar. Just checkout, say,
> 1.9.1-20140308, and recompile.

I may do that later this week (rather busy using gschem at the moment),
but I am 100% certain that this behaviour started from the very moment
that a regular update pulled in the version with both the sidebar and
the status bar.

Best regards,

Richard Rasker