On Fri, 2015-08-14 at 07:51 -0400, Bill Maltby (C4B) wrote: > <snip> > Ksnapshot region selection still lagging and jerky. > > So it would be easy to think some of this A.M.'s updates had a > beneficial effect in one regard, CPU, usage, but not in the clunky > behavior of region selection with Ksnapshot (could be a mouse driver > issue introduced with the 6.7 update?). > > But drawing any conclusion would be premature until I've run a normal > day and see if FF keeps increasing in CPU usage like it normally does, > the java applets, once I've several running, do the same, etc., and see > how Xorg CPU usage and region selection with Ksnapshot behave. Xorg CPU usage did increase, as before, under certain conditions of my test, and held up very high at times when I would not have expected that (like when the things that may have caused it are left idle with no activity for hours on end). Ksnapshot region selection had only minor, if any, improvement. This is subjective, so hard to be certain. > > I'll wrap up this thread this evening and thanks for your help Gordon! > > Bill To spare the list, most of whom likely have little interest, http://pastebin.com/6Gtf99fh contains the gory details of my attempt to find causation. Undertaking it over the weekend when certain possible causes weren't available was not optimal but I don't want to take too much away from my real-life needs to overcome deficiencies introduced by new ... "features". But I would like my 6-core AMD Linux home-built box to perform better than, or at least as well as, my *old* (2009?) 2-core HP AMD Windows 7 (now Windows 10) box. Yeah, it has more memory, 12GB vs. 8GB, and only runs a single user, but that's not enough to make much difference because it runs a really hoggish *huge* Java app all day while my Linux box just runs some spreadsheets and browser activities. Never thought I'd see the day when an *IX box couldn't keep up with that other stuff. One possible good may come from it - a possible clue to where to look next to fix the telinit 3/5 X screw up referenced in the big report posted in the CentOS mantis system back in ... Dec? Since RH doesn't have it I assume the same thing that caused run-level change to stop working correctly when X is active will cause it to not get fixed. On to the topic du jour ... First, a couple minor corrections. I erroneously provided CPU info from one of my other boxes in the OP. Actual CPU is $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1035T Processor stepping : 0 cpu MHz : 800.000 cache size : 512 KB ... cpu cores : 6 ... I also said "openoffice" when it's actually "libreoffice". My preliminary conclusion is there's something in java and/or libreoffice that begins causing load on the X server once activity begins. The full effects of the java applet in FF could not be determined during the attempt to duplicate due to the lack of a data feed Saturday and Sunday. There's apparently something somewhere that holds the X server load high even when the causative items are just sitting idle for extended periods. The Ksnapshot region selection is still clunky (tested again after this latest closing of the all spreadsheets and libreoffice) with noticeable lag to cursor movement and jerky progression of the window borders, as compared to CentOS pre-6.7 update. I doubt I have enough expertise to do anything more that could be worthwhile, but hope that maybe someone who has the interest and expertise might stumble upon, or pursue, a solution. Bill