Re: HEADS-UP: issues with chromium in -current
Hello! This is an older (still gtk+2 based) version of chromium: it doesn't have this bug. The bug started manifesting itself, when they switched to the new Aura toolkit (since version 37 iirc). It happened _after_ the switch to Aura which was in 36.0.1985.125 which is the version that will be in 5.6 release packages, that one was ok. Looking at chat logs, I first mentioned it in September, and I recall that the problem definitely existed with the version immediately before the use GPU accelerated cross process image transport on openbsd as well commit - as I was hoping that might fix it :-). I'm not totally sure because of the lock and lack of snapshots, but I think 36.0.1985.143 is probably okay. I can approve this, as I'm using Chromium 36.0.1985.143 (287914) on: OpenBSD 5.6-current (GENERIC.MP) #2: Fri Sep 5 15:59:11 EEST 2014 with Fluxbox for almost two months now, and it's working rock solid without any issues whatsoever. -- Karlis
HEADS-UP: issues with chromium in -current
This has been discussed internally, but chromium is partly broken these days. Most specifically, windows refresh does strange things under some circumstances. The circumstances are well-known (thanks to matthieu@): modern systems use some composition manager for eye-candy on their display. So if you're using a shiny window manager, you won't see an issue. Old-style window managers, such as fvwm, fvwm2 (from ports) and cwm don't. Hence the breakage. Work-around: start a composition manager, such as xcompmgr from base xenocara. Cry since you lost your background image or moire pattern (fvwm-root, from ports, does know about composition managers). We're currently in the process of reporting the problem upstream. Outside of OpenBSD, most people don't use primitive window managers, so they don't see the issue. It probably started around when chromium switched to Aura for its gfx system...
Re: HEADS-UP: issues with chromium in -current
On Thu, Oct 23, 2014 at 12:14:03PM +0200, Marc Espie wrote: This has been discussed internally, but chromium is partly broken these days. Most specifically, windows refresh does strange things under some circumstances. The circumstances are well-known (thanks to matthieu@): modern systems use some composition manager for eye-candy on their display. So if you're using a shiny window manager, you won't see an issue. Old-style window managers, such as fvwm, fvwm2 (from ports) and cwm don't. Hence the breakage. Work-around: start a composition manager, such as xcompmgr from base xenocara. Cry since you lost your background image or moire pattern (fvwm-root, from ports, does know about composition managers). We're currently in the process of reporting the problem upstream. Outside of OpenBSD, most people don't use primitive window managers, so they don't see the issue. For information. I'm using Slackware 14.1 with fvwm2 and Chromium, I see no issue at all. It probably started around when chromium switched to Aura for its gfx system... -- Stéphane Tougard steph...@unices.org
Re: HEADS-UP: issues with chromium in -current
On Thu, Oct 23, 2014 at 12:58 PM, Stephane Tougard steph...@unices.org wrote: I'm using Slackware 14.1 with fvwm2 and Chromium, I see no issue at all. fvwm2 with or without a compositor (like xcompmgr or compton)? And what version of chromium? Ciao David -- If you try a few times and give up, you'll never get there. But if you keep at it... There's a lot of problems in the world which can really be solved by applying two or three times the persistence that other people will. -- Stewart Nelson
Re: HEADS-UP: issues with chromium in -current
On Thu, Oct 23, 2014 at 12:14:03PM +0200, Marc Espie wrote: This has been discussed internally, but chromium is partly broken these days. Most specifically, windows refresh does strange things under some circumstances. The circumstances are well-known (thanks to matthieu@): modern systems use some composition manager for eye-candy on their display. So if you're using a shiny window manager, you won't see an issue. Old-style window managers, such as fvwm, fvwm2 (from ports) and cwm don't. Hence the breakage. Work-around: start a composition manager, such as xcompmgr from base xenocara. Cry since you lost your background image or moire pattern (fvwm-root, from ports, does know about composition managers). We're currently in the process of reporting the problem upstream. Outside of OpenBSD, most people don't use primitive window managers, so they don't see the issue. It probably started around when chromium switched to Aura for its gfx system... Does this issue include highlighted links becoming invisible? I ask as using xcompmgr does not solve this problem for me in Chromium. My set up: port:fred ~ dmesg|head -2; chrome --version; awesome --version OpenBSD 5.6-current (GENERIC.MP) #462: Tue Oct 21 16:17:54 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Chromium 38.0.2125.101 awesome v3.5.5 (Kansas City Shuffle) ?? Build: Oct 19 2014 10:55:35 for amd64 by gcc version 4.2.1 (@amd64.ports.openbsd.org) ?? Compiled against Lua 5.2.3 (running with Lua 5.2) ?? D-Bus support: ? cheers Fred
Re: HEADS-UP: issues with chromium in -current
On Thu, Oct 23, 2014 at 3:06 PM, Stephane Tougard steph...@unices.org wrote: On Thu, Oct 23, 2014 at 01:04:04PM +0200, David Coppa wrote: I'm using Slackware 14.1 with fvwm2 and Chromium, I see no issue at all. fvwm2 with or without a compositor (like xcompmgr or compton)? Original version of the Slackware. xcompmgr is as well originally part of Slackware. And what version of chromium? 33 This is an older (still gtk+2 based) version of chromium: it doesn't have this bug. The bug started manifesting itself, when they switched to the new Aura toolkit (since version 37 iirc). Ciao, David
Re: HEADS-UP: issues with chromium in -current
Marc Espie, 23 Oct 2014 12:14: This has been discussed internally, but chromium is partly broken these days. Most specifically, windows refresh does strange things under some circumstances. my funny story is with dual head under openbox. when i switch back to the virtual desktop where chrome is, it is gone. until i mouse over it, then it reappears. quite the hide and seek game. Outside of OpenBSD, most people don't use primitive window managers, so they don't see the issue. as 99% of the primitive window managers are developed outside of openbsd, i'd say that is a contradiction. -f -- never test for an error you don't know how to handle.
Re: HEADS-UP: issues with chromium in -current
On 23 October 2014, Marc Espie es...@nerim.net wrote: This has been discussed internally, but chromium is partly broken these days. Most specifically, windows refresh does strange things under some circumstances. The circumstances are well-known (thanks to matthieu@): modern systems use some composition manager for eye-candy on their display. So if you're using a shiny window manager, you won't see an issue. Old-style window managers, such as fvwm, fvwm2 (from ports) and cwm don't. Hence the breakage. Work-around: start a composition manager, such as xcompmgr from base xenocara. Cry since you lost your background image or moire pattern (fvwm-root, from ports, does know about composition managers). We're currently in the process of reporting the problem upstream. According to Linux guys, there's a world of pain in that general direction: http://www.iuculano.it/linux/apt-get-purge-chromium/ Some of the comments there are enlightening too. Outside of OpenBSD, most people don't use primitive window managers, so they don't see the issue. It probably started around when chromium switched to Aura for its gfx system... Regards, Liviu Daia
Re: HEADS-UP: issues with chromium in -current
On 2014-10-23, David Coppa dco...@gmail.com wrote: On Thu, Oct 23, 2014 at 3:06 PM, Stephane Tougard steph...@unices.org wrote: On Thu, Oct 23, 2014 at 01:04:04PM +0200, David Coppa wrote: I'm using Slackware 14.1 with fvwm2 and Chromium, I see no issue at all. fvwm2 with or without a compositor (like xcompmgr or compton)? BTW has anyone looked at writing a port for compton? It is meant to be much better than xcompmgr (from which it originally derived). Original version of the Slackware. xcompmgr is as well originally part of Slackware. And what version of chromium? 33 This is an older (still gtk+2 based) version of chromium: it doesn't have this bug. The bug started manifesting itself, when they switched to the new Aura toolkit (since version 37 iirc). It happened _after_ the switch to Aura which was in 36.0.1985.125 which is the version that will be in 5.6 release packages, that one was ok. Looking at chat logs, I first mentioned it in September, and I recall that the problem definitely existed with the version immediately before the use GPU accelerated cross process image transport on openbsd as well commit - as I was hoping that might fix it :-). I'm not totally sure because of the lock and lack of snapshots, but I think 36.0.1985.143 is probably okay.
