On Tue, Jul 1, 2014 at 9:38 PM, Zev Weiss wrote:

On Jul 1, 2014, at 9:44 AM, Brandon Allbery wrote:

...

On Tue, Jul 1, 2014 at 10:08 AM, Carsten Mattner 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.