I have a game is made by Cocos js.
In the previous version of chrome (79) fps always 60, but when I update new version chrome (80) the fps is slow down, and cpu usage is very high in mac. But when I turn off "Automatic graphics switching" in "Energy Saver", fps has 60.
I already download version 79 for reproduce it, and fps performance is ok.
Firefox don't have this issue.
So any one know how to fix it?
Thank you
I was in the same boat. Adding powerPreference: 'high-performance' (hyphenated) to my context creation params fixed it.
Example:
canvas.getContext('webgl', {
alpha: false,
antialias: true,
powerPreference: 'high-performance',
});
This announcement has a lot more info:
https://www.khronos.org/webgl/public-mailing-list/public_webgl/1912/msg00001.php
And there are more details about the powerPreference param here: https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1
Related
I found libGLESv2.dylib libswiftshader_libGLESv2.dylib libvk_swiftshader.dylib in Chrome.app. And in https://webglreport.com/?v=2 it says:
Vendor: WebKit
Renderer: WebKit WebGL
Unmasked Vendor: ATI Technologies Inc.
Unmasked Renderer: AMD Radeon Pro 560X OpenGL Engine
Antialiasing: Available
ANGLE: No
I heard that chrome uses angle on windows. Here angle is not used on macOS. So how does chrome run webgl?
There is no way to detect ANGLE. WebGLReport guesses and its guess are wrong. Here is their code
function getAngle(gl) {
var lineWidthRange = describeRange(gl.getParameter(gl.ALIASED_LINE_WIDTH_RANGE));
// Heuristic: ANGLE is only on Windows, not in IE, and not in Edge, and does not implement line width greater than one.
var angle = ((navigator.platform === 'Win32') || (navigator.platform === 'Win64')) &&
(gl.getParameter(gl.RENDERER) !== 'Internet Explorer') &&
(gl.getParameter(gl.RENDERER) !== 'Microsoft Edge') &&
(lineWidthRange === describeRange([1, 1]));
if (angle) {
// Heuristic: D3D11 backend does not appear to reserve uniforms like the D3D9 backend, e.g.,
// D3D11 may have 1024 uniforms per stage, but D3D9 has 254 and 221.
//
// We could also test for WEBGL_draw_buffers, but many systems do not have it yet
// due to driver bugs, etc.
if (isPowerOfTwo(gl.getParameter(gl.MAX_VERTEX_UNIFORM_VECTORS)) && isPowerOfTwo(gl.getParameter(gl.MAX_FRAGMENT_UNIFORM_VECTORS))) {
return 'Yes, D3D11';
} else {
return 'Yes, D3D9';
}
}
return 'No';
}
It's wrong and years out of date.
The first guess is looking at lineWidthRange which even when they wrote it was only a guess. The spec says it is valid to have only lines of width 1. Back when WebGL shipped it was common that ANGLE supported just lines of size 1 and OpenGL supported others. But, that changed when WebGL2 shipped because WebGL2, when running on top of desktop OpenGL, required using the "Core" profile and the "Core" profile disallows lines other than size 1 period.
From the spec
E.2.1 Deprecated But Still Supported Features
The following features are deprecated, but still present in the core profile. They
may be removed from a future version of OpenGL, and are removed in a forwardcompatible context implementing the core profile.
Wide lines - LineWidth values greater than 1.0 will generate an INVALID_VALUE error
Their second guess is looking at the browser. That's obviously no longer valid. Edge is now based on Chromium and further Safari now uses ANGLE as well.
The last one is one more guess that ANGLE is being used because it assumes ANGLE is running on top of D3D and that certain limits were therefore special but ANGLE is now used on all platforms and can run on top of Desktop OpenGL, D3D, OpenGL ES, Metal, and Vulkan. From the chart on the angle project as of January 2021
Level of OpenGL ES support via backing renderers
Direct3D 9
Direct3D 11
Desktop GL
GL ES
Vulkan
Metal
OpenGL ES 2.0
complete
complete
complete
complete
complete
complete
OpenGL ES 3.0
complete
complete
complete
complete
in progress
OpenGL ES 3.1
incomplete
complete
complete
complete
OpenGL ES 3.2
in progress
in progress
in progress
And here is the list of platforms ANGLE currently supports
Platform support via backing renderers
Direct3D 9
Direct3D 11
Desktop GL
GL ES
Vulkan
Metal
Windows
complete
complete
complete
complete
complete
Linux
complete
complete
Mac OS X
complete
in progress
iOS
planned
Chrome OS
complete
planned
Android
complete
complete
GGP (Stadia)
complete
Fuchsia
in progress
So, you shouldn't believe WebGLReport. Maybe you should go file a bug.
Chrome is able to use desktop OpenGL on MacOS to run WebGL but AFAIK ANGLE is used on all Chrome platforms at this point in time including MacOS. ANGLE was even added to Safari recently to enable Safari's WebGL2 support and to fix a bunch of bugs with their WebGL1 support
In my Angular application, after introducing some more heavy usage of ngxs, I see my application has been come very slow when the inspector is open, but not when the profiler is running.
This has made it a little hard to figure out what's going on, but using the old conosle.profile method (adding an entry to Chrome's old profiler), I've narrowed it down a little - but I'm not at all more informed now than I was - just more confused.
So here's to hoping someone here can help me out!
I have some screenshots from the profiling to share, but unfortunately not much else.
First, a screenshot from the profile chart:
As you can see, there's a looooong time, where apparently nothing is really happening. Note in the console, that the bottom method (startObserving) only takes .12ms (according to console.time)
Going up the tree a few steps, we find Handsontable - this is what the function looks like, and some timings associated:
function Handsontable(rootElement, userSettings) {
console.time('Handsontable total time');
console.time('Handsontable create instance');
var instance = new _core2.default(rootElement, userSettings || {}, _rootInstance.rootInstanceSymbol);
console.timeEnd('Handsontable create instance');
console.time('Handsontable init instance');
instance.init();
console.timeEnd('Handsontable init instance');
console.timeEnd('Handsontable total time');
return instance;
}
// Timer outputs:
// This looks OK
Handsontable create instance: 10.864990234375ms
// Also this
Handsontable init instance: 1462.807861328125ms
// Wow, what??
Handsontable total time: 52664.875ms
It looks like the 2 methods called in the Handsontable constructor/function have a total run-time of <1500ms, but the total execution time is more than 52 seconds.
What in the world can be happening in those ~50 seconds of - as I see it - idle time?
Any help is really welcome, hints, suggestions, help to better debug!
Note: In Firefox, this is not an issue. I've tried in Chromium 67, 68 and 69 too - same issue. It's a problem in Chrome across all platforms (tested in Windows 10, Ubuntu 16,17 and MacOS latest-1,latest)
I am creating an app on iOS in Flash Builder, with as3.
The app uses the Starling plugin: http://wiki.starling-framework.org/start
My app allows users to take photos and customise them. When attempting to access the camera or camera roll on iOS 8, I get the error message "The application lost the device context!".
On Android, I can get around this problem with this line:
Starling.handleLostContext = true;
But I am told that iOS should never lose context (and I haven't seen it lose context on iOS 7 or below).
If I include that line in iOS 8, the application crashes at around the same point, but in this case the app crashes completely, and returns me to the home screen rather than displaying the previous message.
I have heard there are restrictions on iOS 8 with regards to the use of 64 bit/32 bit plugins and extensions, but I am not using any ANEs in this particular app. Are there any other areas where 32-bit could be causing problems or is that strictly related to ANEs?
I don't get this error on iOS 7 or below or Android, unless I set handleLostContext to false.
Adobe Scout provides no error message.
Any help would be appreciated.
UPDATE:
This code calls in the camera functionality:
var cameraRoll:CameraRoll = new CameraRoll();
if(CameraRoll.supportsBrowseForImage) {
trace("camera rolling");
cameraRoll.addEventListener(MediaEvent.SELECT, imageSelected);
cameraRoll.addEventListener(flash.events.Event.CANCEL, browseCanceled);
cameraRoll.addEventListener(flash.events.ErrorEvent.ERROR, galleryMediaError);
cameraRoll.browseForImage();
} else {
var alert:Alert = Alert.show("Image browsing is not supported on this device.", "Error", new ListCollection([{label:"OK"}]));
}
UPDATE 2:
I've switched from AIR SDK 17 to 16, and it is now more stable but has similar issues
There is a known issue with the camera roll in iOS which will cause stage3d to lose context. Your options:
Set Starling.handleLostContext = true, it is possible to lose context in iOS.
Find an ANE (Supposedly these exist) that handles the camera roll without losing context.
More Information:
http://forum.starling-framework.org/topic/starling-and-cameraui#post-77339
I can confirm on ios 8.3 a Context3D is not lost when opening the CameraRoll using AIR 18.
Make sure you are using AIR 18.
Make sure you are using the latest Starling Version.
If the problem persist it's likely Starling is the cause.
Either report the problem and wait for an update.
Do not use Starling when requesting the CameraRoll (turn Starling off and Display normal Bitmaps).
Don't use Starling and use another engine or create your own.
It was said that getUserMedia would land on Firefox OS 1.2. I have read the documentation and tried to look for it in the Google Groups, but I have not found anything related to it.
I have developed a web app that works on Firefox Nightly (so, it works in Gecko):
But when I try to use it in Firefox OS 1.4, I get a "Permission denied" error:
I have tried to add the following permission to the manifest:
"permissions":{
"camera":{}
}
But didn't solve the problem. Is there any other permission that I would need to add?
getUserMedia support for the microphone landed in FxOS v1.2. getUserMedia support for the camera just landed on trunk (v1.4) about a week ago. The final piece to land was support for permission prompts : bug 853356 in bugzilla.mozilla.org (https://bugzilla.mozilla.org/show_bug.cgi?id=853356). Prior to a week ago, you would have gotten a permission error.
Currently the camera always returns frames in landscape mode. Bug 970183 (https://bugzilla.mozilla.org/show_bug.cgi?id=970183) tracks that problem, and we're actively working to land a fix for this ASAP.
you need add video-capture permissions in manifest.webapp in 1.4 for getUserMedia video,
and audio-capture permissions in manifest.webapp in 1.2 for getUserMedia audio, ex:
"permissions": {
"audio-capture": {},
"video-capture": {}
}
As the title says, if I have an audio node that emits sound and I connect it to two separate GainNodes, which in turn are connected to the Audio Context destination, the sound plays at double speed / double pitch (as if half samples are sent to one gain node and half samples to the other, and the time is halved as well).
I have created an handy jsfiddle here, just drag your sound files in the black rectangle canvas and listen.
// audioContext: Web Audio context
// decoded: decoded audioBuffer
// gainNode1, gainNode2: gain nodes
var bSrc = audioContext.createBufferSource();
bSrc.connect (gainNode1);
bSrc.connect (gainNode2);
gainNode1.connect (audioContext.destination);
gainNode2.connect (audioContext.destination);
bSrc.buffer = decoded;
bSrc.loop = false;
// You'll hear two double-speed buffers playing at unison
bSrc.start(0);
Is that by design? What I would like is to exactly "duplicate" the sound (that will be sent to two different routes, the fiddle is just a proof-of-concept for a bigger project).
Edit:
I tested this on Chrome Version 24.0.1312.56 / Ubuntu 12.10 and the behaviour is present.
The behaviour is also present on Chrome Version 24.0.1312.68 / Ubuntu 12.10
On Chrome Version 24.0.1312.57 / Mac OSX, the Audio API works well and this behaviour is not present.
Could it be a Linux-only issue?
Sounds like a Linux implementation issue. It works for me in Chrome on OS X.