complete failure on a lenovo T440 running an up-to-date Fedora 21 instance. process starts, lots of console errors, and then a completely dark screen. no bits painted whatsoever. input events ignored. ugh.
Is is just me, or has this latest Dev build completely broken things on OSX as well?
I'm on OSX 10.9.5, and the CPU usage on a whole bunch of sites (e.g. Gmail, YouTube etc.) is consistently high (i.e. near 80%), to the point where it's essentially lagging and unusable...
I was able to launch with the --disable-gpu flag. I still need --force-device-scale-factor=1 after the last update made everything including the UI Chrome double size.
for a lenovo T440 w/intel graphics running Fedora 21, simply setting the MESA env vars sufficed. no scaling issues (but the T440 is not one of those high-res displays).
This version has a big problem on Ubuntu 14.04. The interface is now 2 or 3 times bigger than before. Look here for a side by side comparison with Firefox. Chrome is not longer usable right now.
one small thing i've noticed - my one character search engine aliases (e.g. "w" for wikipedia) aren't recognized always. haven't found a way to reproduce it reliably. but it happens frequently (50% of the time?).
starting chrome with the MESA env var settings is still difficult. it fails to start often (90% of the time?) and generates multiple crash dumps for each attempt. i haven't found a pattern of 'kill' or 'kill -9' invocations combined with 'echo 3 > /proc/sys/vm_drop_caches' that works around it. feels like black magic at this point. once started successfully, it runs without a problem.
Follow
19 comments :
complete failure on a lenovo T440 running an up-to-date Fedora 21 instance. process starts, lots of console errors, and then a completely dark screen. no bits painted whatsoever. input events ignored. ugh.
Confirm black screen issues in Ubuntu 14.10
Confirm catastrophic failure in Debian Jessie.
Is is just me, or has this latest Dev build completely broken things on OSX as well?
I'm on OSX 10.9.5, and the CPU usage on a whole bunch of sites (e.g. Gmail, YouTube etc.) is consistently high (i.e. near 80%), to the point where it's essentially lagging and unusable...
How's the Windows build? Should we be holding off on updating too?
Nah, Windows is fine.
There is a new flag for Slimming Paint on about:flags, but I wouldn't turn it on yet, as it breaks scrolling on various sites.
The new release makes use of GLSL 1.5 shaders which are not support in the Linux Mesa drivers by default. You can enable the support as follows:
export MESA_GL_VERSION_OVERRIDE=3.3
export MESA_GLSL_VERSION_OVERRIDE=330
... and launch chrome ;)
confirm that the MESA env var settings work on Fedora 21.
I was able to launch with the --disable-gpu flag. I still need --force-device-scale-factor=1 after the last update made everything including the UI Chrome double size.
for a lenovo T440 w/intel graphics running Fedora 21, simply setting the MESA env vars sufficed. no scaling issues (but the T440 is not one of those high-res displays).
setting env var is not woked for me
i'm using xorg-edgers ppa
Alternatively, if your driver lacks OpenGL 3.3 support, you can try 3.2:
export MESA_GL_VERSION_OVERRIDE=3.2
export MESA_GLSL_VERSION_OVERRIDE=150
@ Daniel & the team
The "Current Release Information" table on https://www.chromium.org/developers/calendar hasn't been working for several weeks now.
MESA_GL_VERSION_OVERRIDE=3.3COMPAT google-chrome-unstable
^ this one worked
This version has a big problem on Ubuntu 14.04. The interface is now 2 or 3 times bigger than before.
Look here for a side by side comparison with Firefox.
Chrome is not longer usable right now.
one small thing i've noticed - my one character search engine aliases (e.g. "w" for wikipedia) aren't recognized always. haven't found a way to reproduce it reliably. but it happens frequently (50% of the time?).
bhsand, thanks for notifying us about the release information page - it should be fixed now!
starting chrome with the MESA env var settings is still difficult. it fails to start often (90% of the time?) and generates multiple crash dumps for each attempt. i haven't found a pattern of 'kill' or 'kill -9' invocations combined with 'echo 3 > /proc/sys/vm_drop_caches' that works around it. feels like black magic at this point. once started successfully, it runs without a problem.
Post a Comment