[xmonad] Chromium floating required

Carsten Mattner carstenmattner at gmail.com
Wed Jul 2 20:03:10 UTC 2014


On Tue, Jul 1, 2014 at 9:38 PM, Zev Weiss <zev at bewilderbeest.net> wrote:
>
> On Jul 1, 2014, at 9:44 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
>
>> On Tue, Jul 1, 2014 at 10:08 AM, Carsten Mattner <carstenmattner at gmail.com> wrote:
>> I tried current Chromium and Chrome to test some websites and found out that
>> the new version requires for Chromium to be floating or else there's
>> glitches and corrupted drawing.
>>
>> Anyone else seen this?
>>
>> I'm not seeing this in the most recent Chrome on Fedora 19, but
>> it's running in a VM. Are you using an NVidia driver in xorg, by
>> any chance?
>>
>
> I saw similar misbehavior from Chromium on Debian Jessie on some
> recent releases -- I didn't think to associate it with xmonad
> though, and haven't tried floating its windows to see if it goes
> away. Frankly I just figured it was Chromium breakage and got so fed
> up with it (and various other bits of Chromium stupidity) that I've
> started mostly just using Firefox instead. (And no, no NVidia stuff
> on my system, just Haswell integrated graphics via i915.ko.)
>
> But of course now I can't reproduce it, so it may be that some minor
> Chromium update in the interim (now on 35.0.1916.153-2) has fixed
> it, or at least made it less egregious.

Only i915 here too and Chromium 38.0.2080.0 without floating rule
doesn't glitch but redraws of window contents (html body) are very
slow if I don't enable floating. This must be be all caused by
the new Aura backend. Tried with floating reenabled and same
window size as non-floating and there's no such visible redrawing
you can watch happen. Good thing Chromium is not my main browser
but in floating mode Aura doesn't fail as miserably. Someone with
more Xlib experience may find out something interesting I guess.


More information about the xmonad mailing list