Not sure if this is a new problem with Chrome, but video that has been working for ages is suddenly showing as black and I get the below error when rendering.
The video size is 1920x1080
[.Offscreen-For-WebGL-08FD8CF0]GL ERROR :GL_INVALID_VALUE :
glCopySubTextureCHROMIUM: source texture bad dimensions.
I'm using video as a ShaderMaterial on a sphere for VR video.
Is this something to do with a recent update or something I'm doing!?
Thanks to #gman for tracking down the bug.
It looks like this is a (known) regression in Chromium, which is the engine that drives Google Chrome. It affects Version 57.0.x.x (Version 57.0.2987.133 in my case, both Windows 7 and Ubuntu - others report the issue on Macs). It seems that the issue occurs when trying to play a video with "elongated pixels", and goes away when playing a video with "square pixels". Not a video processing expert here, but that's what I've derived from the thread. A work-around would be re-encoding/re-transcoding your videos, if you can.
Based on the Chrome stable release schedule, version 58 will be out 4/25/2017 (source), and based on the bug thread, it should hopefully be fixed by then.
Edit: This should be fixed in Chrome 58 and Chrome 59 (source).
Related
TL;DR Canvas Elements not showing up for some sites and does show for others. How can I have it show consistently?
I have a 2021 Macbook Pro with an Apple M1 Pro processor. I use Chrome Browser v105.0. On some sites that use the HTML5 canvas element, I am able to see stuff being drawn on the canvas but for other sites, the canvas element is clearly there but nothing is drawn on it. I tried playing with the chrome://flags that have to do with GPU and Canvas by switching them on and off to see if I can get Canvas Elements showing up consistently and now they do show for the sites that it was not working for but only after refreshing the page.
Has any one experienced this before and if so, is there a way that I can have canvas elements show consistently without all the workaround?
I am experiencing the same issue with HTML5 canvas on Chrome M1, seems to be related to Apple Silicon (M1) + Chrome 105 because it's working fine on Chrome v105, on a Windows/MacOs Intel computer. It is fixable (on your client only) by disabling the 'Out-of-process 2D canvas rasterization' flag on chrome://flags. Still waiting Google to fix this issue as it is a breaking issue.
Edit : tested on Chrome Beta (v106.0.5249.30) and the issue is still present
We experience the same problem (only with the Apple M1 processor, Apple M2 not tested). We developed an app using the canvas element. It worked fine with Apple M1 and Chrome (till v104). When Chrome v105 was launched the problem started and the canvas element didn't draw anything anymore. The problem only occurs when the flag accelerated 2d canvas is enabled. When this flag is disabled the canvas works fine again. This is a breaking issue and should be fixed by Google. Everything works fine in the latest version of Safari and Firefox with acceleration enabled.
The problem is fixed with Google Chrome v107. Topic can close.
I cannot make Google Chrome tile correctly in Awesome WM (version 4.3 in Debian 10 & 11). Chrome's window stops responding, or goes blank, if it is resized (a new tile is added next to it, or a tile is closed/minimized), or when it's open in floating mode.
This weird behavior started with the recent version of Chrome (probably, 86). Only Chrome is affected, Firefox and all other applications I use work without problems.
I tried running Chrome with debug log, but there is nothing helpful there. No error messages appear, neither in journalctl nor in ~/.xsession-errors.
Did anyone experience anything like this before?
The problem was resolved after disabling "hardware acceleration" in Chrome. Seems like this feature didn't work well on my system (intel hd graphics 4400 and Awesome WM).
I'm working on a project using KineticJS version 4.6 (currently the latest version), and since last night's Chrome update to Chrome 29, the Kinetic canvas is completely blank. While using the console, I am still able to detemine that the created objects, such as the Kinetic.Stage and Kinetic.Layer, still exist and are filled with correct data.
Afterwards, I tried loading the same page in Internet Explorer and Firefox, and they still work as intended, showing the canvas with the correct elements.
I have tried searching for people with similar issues, but I guess Chrome's update is too recent to show any results. Does anyone perhaps know if there is a way to fix it or if I should simply wait for either a KineticJS or a Chrome update?
EDIT: And now it suddenly works again after restarting Chrome. Hotfixed?
EDIT2: After a while it broke again, but restarting the browser seems to work
EDIT3: It is a bug in Chrome, acknowledged by the Chromium team in this thread. The thread states that the bug is definitely fixed in version 30, which is currently in beta. This fix may be merged in version 29 soon, but there is no definitive timetable for this.
We have the same problem in Chrome 29.
In some cases a workaround is to tell your users to use Chrome Incognito mode to fix this issue.
A test to replicate the issue consistently is posted here:
https://github.com/ericdrowell/KineticJS/issues/585
At present, the bug is not present in Chrome 30. (8/27/2013)
You should star this chromium issue:
https://code.google.com/p/chromium/issues/detail?id=280153
I'm trying to understand these strange rendering error boxes that are too big to be ignored. This seems to happen on Chrome in Windows 7 (my testing isn't too elaborate) and nowhere else. When I attempt to inspect, they all disappear. This could be some kind of video card issue as I'm using some pretty advanced CSS3 transitions that could mess up memory. In any case, if someone could offer advice on what I could do to fix, I'm at a loss. The site is www.crane-usa.com
Having the same issue with our site using 21.0.1180.89 and 21.0.1180.79. Problem is in Windows 7, Mac OS X latest, Ubuntu and in Chrome frame running in IE9. IE9 with Chrome frame disabled works fine. The problems are intermittent and unrepeatable. Inspect element removes the problem as you say. I tried disabling GPU compositing via chrome://flags but that didn't fix the issue.
We and our users have only been seeing these issues since approx Aug 27, 2012, 3 days ago. I took a look in crbugs.com and found that this seems to have existed for a couple of weeks already. http://code.google.com/p/chromium/issues/detail?id=143647
Sorry our site is not public so I can't post our url but you're not alone.
I'm not really sure what is causing this but in the current stable version of safari on OSX 10.7.X I'm only seeing 3-4 frames rendered. I downloaded the lastest safari beta and it seems like they improved it, but its still dropping a large amount of frames.
Here is an demo that should be viewed in Safari on Lion:
http://jsfiddle.net/JEKAh/1/
Please respond if you know why or what is going on
edit: still is a problem on mountain lion
It turns out that this bug is related to the transfer encoding of the video files. If you are sending the video with Content-Ranges you will see this issue in safari. But if you send the video using Transfer-Encoding: chunked... it will work fine
I used a simple node server to test this: https://gist.github.com/3746561/c303f84866542c4a6ec2956ecf158cb9f492a7a2
-- edit
the above is only a fix for Lion, it appears that Safari Mountain Lion is unable to render frames from a video that is sent using a chunked transfer encoding, a side affect of this is also massive safari memory leaks... I ran a video being piped for canvas for 2 mins and the Safari Web Content process shot up to 12GB of real mem used. -_-
-- edit
after additional research i have found the original issue with standard video to canvas in a recent nightly webkit 537.3 and have confirmed that currently in webkit 537.11 these issues no longer exist... so all i can do is hope that apple updates safari soon including the webkit fixes
-- edit
this is now fixed in OSX 10.9 :)
Firstly, I acknowledge that this might not be the answer you are looking for but it's something which I've just been dealing with for a client so I thought I'd throw it up here:
They reported that their site "Was no longer working well and the animation was jumpy".. (hmm..) Their site uses canvas rendered videos with some overlays for a lot of the visual elements.
So after a while we determined that they had just updated their MacBook Pro to Lion and now their site was slower and less responsive. I was a bit baffled so I got them to bring it to me. To cut to the chase:
Lion & Mountain Lion require a tonne more physical memory (RAM) than Snow Leopard did (due to the new VM architecture as I understand it), I compared their site playback to another MBP with a lower spec, with SL installed and the SL version ran smoother.
After a bit of reading on the Apple support forums which suggested adding RAM, it was all fine again, in fact it seemed smoother than ever..
Not really a programatical answer but one which I thought may be relevant..