Openbox and --disable-xsync

Other talk about Salix
Post Reply
GJones
Donor
Posts: 300
Joined: 22. Jul 2011, 23:27

Openbox and --disable-xsync

Post by GJones » 3. Mar 2013, 04:32

When you have the time, try this...

1. Download and untar the latest Openbox sources: http://openbox.org/wiki/Openbox:Download

2. ./configure --disable-xsync; make; make install; ldconfig

3. openbox --replace

Now do some basic desktop stuff, and tell me: does it seem faster?

Also: does the output of powertop look different? If you're on a laptop, how's its battery life looking?

(I especially encourage people to try this on netbooks, and other really low-end computers.)

User avatar
jayseye
Posts: 233
Joined: 24. Jul 2011, 17:22
Location: Brownsmead, Oregon (Center of the Universe)

Re: Openbox and --disable-xsync

Post by jayseye » 3. Mar 2013, 05:38

Sounds interesting though I'd like to understand the details, including any possible disadvantages.

Ideally, djemos would incorporate this into the Salix and/or Slackel Openbox packages.

Thanks!

GJones
Donor
Posts: 300
Joined: 22. Jul 2011, 23:27

Re: Openbox and --disable-xsync

Post by GJones » 3. Mar 2013, 06:39

A WM uses the XSync extension to synchronize redraws of the WM decorations and the window contents. Disabling XSync at compile time removes that capability; without it, window frames will move out of sync with window contents.

Advantages of XSync: because unnecessary resize events are avoided, there should be less network traffic when using a remote desktop, and likewise probably less CPU usage locally.

Disadvantages of XSync: it visibly slows down window resizing, making the desktop appear slower and less responsive. Whether it produces any actual loss of performance on a local desktop, I have no idea; though based on the behavior of KDE with XSync-enabled vs. XSync-disabled window managers, it sure looks as though there's some bona fide lag.

My take: wait on it until we know the full impact on battery life and remote desktops. Battery life especially. Powertop is telling me that X is causing a lot of wakeups at the moment; it might be because Opera doesn't like these forums (it does chug CPU on some websites), but it might also be due to my disabling XSync in Openbox. We'll see.

Edit: Okay, the wakeups were just Opera acting up.

Actually, re battery life and network traffic, I'll note that some of the lighter window managers - most notably Fvwm and IceWM - do not support XSync... Probably all is well on that front. Still, I think I'd better do more testing before I declare this WM feature detrimental.

GJones
Donor
Posts: 300
Joined: 22. Jul 2011, 23:27

Re: Openbox and --disable-xsync

Post by GJones » 3. Mar 2013, 14:48

Okay, CPU usage without XSync is about 80% on my Pentium D laptop when resizing a Konqueror window, vs. 60% with XSync. I'm not sure what, if any, realistic impact this might have on batter life.

Also performance when compositing (with xcompmgr) seems genuinely better; windows don't lag nearly as much during resize.

Edit: though the latter may not be accurate, because xcompmgr is not drawing shadows properly ATM. Not sure why.

GJones
Donor
Posts: 300
Joined: 22. Jul 2011, 23:27

Re: Openbox and --disable-xsync

Post by GJones » 3. Mar 2013, 19:04

Hmm. It looks like, in at least some cases, the feeling of sluggishness is more than just psychological:

https://bugs.launchpad.net/compiz/+bug/1049214

Apparently the functions involved are expensive in terms of CPU time. OTOH
A test for disabling XSync completely (which will cause bugs but be a great performance comparison) would be to write a stub XSync function and LD_PRELOAD it into compiz. I will try to do that soon.
There may be further disadvantages to not using XSync at all. I would guess those issues would be more in compositing WMs like Compiz (tearing, etc.) but you never know. I will look into it.

Edit: OTOH, I just talked with one of the KDE developers and was informed that disabling XSync would probably create bigger bottlenecks. It could well be that, in this case, the "performance benefit" is all in the user's head; i.e. window frames resizing more smoothly, and appearing sooner when their contents have not yet rendered, giving a false impression of speed.

Still looks much better without XSync than with though. This is the only tweak I know of that makes KDE 4 feel snappy on my laptop.

Edit again: sorry, please ignore that bit about Compiz; the XSync() function is completely different and has nothing to do with the XSync extension.

GJones
Donor
Posts: 300
Joined: 22. Jul 2011, 23:27

Re: Openbox and --disable-xsync

Post by GJones » 5. Mar 2013, 23:07

A final note: Openbox comes with a saner solution built in - an improved implementation of outline resize, which resizes the window frame, but doesn't request a resize of the contents until you let go of the cursor. This doesn't look quite as nice, but otherwise has fewer disadvantages.

User avatar
jayseye
Posts: 233
Joined: 24. Jul 2011, 17:22
Location: Brownsmead, Oregon (Center of the Universe)

Re: Openbox and --disable-xsync

Post by jayseye » 6. Mar 2013, 01:51

Thanks for all the detailed follow-up. Seems like we've already got an optimal solution, then. A good balance between apparent speed, acceptable appearance and, especially, stability.

Post Reply