Welcome to awesome bug tracking system.

FS#1071 - 3.5 release is very slow

Attached to Project: awesome
Opened by Yauhen Kharuzhy (jekhor) - Tuesday, 01 January 2013, 14:10 GMT
Last edited by Uli Schlachter (psychon) - Wednesday, 26 March 2014, 09:08 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System Linux
Severity High
Priority Normal
Reported Version 3.5
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No


After upgrade to 3.5, window moving, resizing, re-arrangement, focus changing operations are very slow.

Similar report is found at Arch Linux forums: .

I have Intel GM965 video adapter, Debian unstable distro.
This task depends upon

Closed by  Uli Schlachter (psychon)
Wednesday, 26 March 2014, 09:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  Here is what the reporter just submitted in a close request:

This bug is not reproduced in 3.5.2 (checked with --no-argb). Other issues from comments should be moved into different bugreports, I think.
Comment by Uli Schlachter (psychon) - Tuesday, 01 January 2013, 14:28 GMT
How much does starting awesome with "--no-argb" help?
Comment by Yauhen Kharuzhy (jekhor) - Tuesday, 01 January 2013, 14:54 GMT
Yes, with --no-argb awesome perfomance is visually same as in 3.4.14.
Comment by Yauhen Kharuzhy (jekhor) - Tuesday, 01 January 2013, 19:51 GMT
There is another problem with perfomance: any change in one window causes redrawing of all windows. It's very annoying and slow when small dialog windows or notification pop-ups causes flashing at entire desktop.
Comment by Karl Onars (karl) - Wednesday, 02 January 2013, 06:34 GMT
Not sure if directly related, but just to let you know, I noticed many other application specific problems, which are all fixed by --no-argb.

For example, moving an Audacious window causes it to be anchored to the top left corner of the screen (See ""), switching to fullscreen view in Feh takes ages and causes the window to lose focus, pseudo-transparent urxvt windows *sometimes* decide to go opaque, etc...
Comment by Uli Schlachter (psychon) - Wednesday, 02 January 2013, 09:10 GMT
Just a small note: "--no-argb" doesn't change much on awesome's sides. All the various bugs are in the video driver (perhaps even the "general slowness", although a good video driver should be able to optimize that).
Comment by Dimitri (duckgrindrr) - Friday, 11 January 2013, 12:15 GMT
Adding "--no-argb" did not make a noticeable difference for me. Resizing windows with the mouse is especially slow.
AMD HD4200 / xf86-video-ati 1:7.0.0 under ArchLinux x86.
Comment by Tim Roes (timroes) - Thursday, 24 January 2013, 22:31 GMT
Same issue here. --no-argb seems to have solved it, or at least it feels way better.
Comment by Timothy Wallis (tjwallis) - Monday, 04 February 2013, 10:37 GMT
Adding --no-argb makes no difference for me well using the xf86-video-ati drivers under ArchLinux x86_64. But using the official AMD drivers seems to fix the problem, don't even need --no-argb.
Comment by Tim Y (tdy) - Monday, 18 March 2013, 16:34 GMT
Runs smoothly for me now on git/master v3.5-53-ga484ef0
Comment by Uli Schlachter (psychon) - Wednesday, 03 April 2013, 20:50 GMT
How much did awesome 3.5.1 help? For the remaining issue, I am hoping that will help.
Comment by Gian Silve (bebop) - Friday, 28 June 2013, 22:15 GMT
I tried with --no-argb but haven't any differences
Using xf86-video-in4tel under ArchLinux x86_6
Comment by Michael (hede) - Monday, 08 July 2013, 09:59 GMT
tried --no-argb option but still higher permanent CPU load with awesome 3.5 (using
awful.widget.graph with vicious.widgets.cpu, awesome 3.5.1, see  FS#1166 )
Intel GMA here.
Comment by Juan Perez (douteiful) - Wednesday, 21 August 2013, 08:31 GMT
I had very serious video tearing problems with Awesome 3.5 and using the --no-argb option fixed the issue completely for me.
I also get some CPU usage (3-4%) by Awesome and Xorg even when idle while using vicious widgets, though.