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
Related
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
When execute ps -ef on my machine, I found a very strange/special command line parameter of chrome:
501 536 493 0 二11上午 ?? 13:11.48 /Applications/Google Chrome.app/Contents/Versions/69.0.3497.100/Google Chrome Helper.app/Contents/MacOS/Google Chrome Helper --type=gpu-process --field-trial-handle=3535656472344341962,3817030915272013891,131072 --gpu-preferences=KAAAAAAAAACAAAAAAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAADgBAAAmAAAAMAEAAAAAAAA4AQAAAAAAAEABAAAAAAAASAEAAAAAAABQAQAAAAAAAFgBAAAAAAAAYAEAAAAAAABoAQAAAAAAAHABAAAAAAAAeAEAAAAAAACAAQAAAAAAAIgBAAAAAAAAkAEAAAAAAACYAQAAAAAAAKABAAAAAAAAqAEAAAAAAACwAQAAAAAAALgBAAAAAAAAwAEAAAAAAADIAQAAAAAAANABAAAAAAAA2AEAAAAAAADgAQAAAAAAAOgBAAAAAAAA8AEAAAAAAAD4AQAAAAAAAAACAAAAAAAACAIAAAAAAAAQAgAAAAAAABgCAAAAAAAAIAIAAAAAAAAoAgAAAAAAADACAAAAAAAAOAIAAAAAAABAAgAAAAAAAEgCAAAAAAAAUAIAAAAAAABYAgAAAAAAABAAAAAAAAAAAAAAAAUAAAAQAAAAAAAAAAAAAAALAAAAEAAAAAAAAAAAAAAADAAAABAAAAAAAAAAAAAAAA0AAAAQAAAAAAAAAAAAAAAPAAAAEAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAAAAABIAAAAQAAAAAAAAAAAAAAATAAAAEAAAAAAAAAABAAAABQAAABAAAAAAAAAAAQAAAAsAAAAQAAAAAAAAAAEAAAAMAAAAEAAAAAAAAAABAAAADQAAABAAAAAAAAAAAQAAAA8AAAAQAAAAAAAAAAEAAAAQAAAAEAAAAAAAAAABAAAAEgAAABAAAAAAAAAAAQAAABMAAAAQAAAAAAAAAAQAAAAFAAAAEAAAAAAAAAAEAAAACwAAABAAAAAAAAAABAAAAAwAAAAQAAAAAAAAAAQAAAANAAAAEAAAAAAAAAAEAAAADwAAABAAAAAAAAAABAAAABAAAAAQAAAAAAAAAAQAAAASAAAAEAAAAAAAAAAEAAAAEwAAABAAAAAAAAAABgAAAAUAAAAQAAAAAAAAAAYAAAALAAAAEAAAAAAAAAAGAAAADQAAABAAAAAAAAAABgAAAA8AAAAQAAAAAAAAAAYAAAAQAAAAEAAAAAAAAAAGAAAAEgAAABAAAAAAAAAABgAAABMAAAAQAAAAAAAAAAcAAAAFAAAAEAAAAAAAAAAHAAAACwAAABAAAAAAAAAABwAAAA0AAAAQAAAAAAAAAAcAAAAPAAAAEAAAAAAAAAAHAAAAEAAAABAAAAAAAAAABwAAABIAAAAQAAAAAAAAAAcAAAATAAAA --service-request-channel-token=17030867567105907743
For curiosity, I find the source of chromium, which seems very normal:
namespace gl {
// On dual-GPU systems, expresses a preference for using the integrated
// or discrete GPU. On systems that have dual-GPU support (see
// GpuDataManagerImpl), resource sharing only works between
// contexts that are created with the same GPU preference.
//
// This API will likely need to be adjusted as the functionality is
// implemented on more operating systems.
enum GpuPreference {
GpuPreferenceNone,
PreferIntegratedGpu,
PreferDiscreteGpu,
GpuPreferenceLast = PreferDiscreteGpu
};
} // namespace gl
So, is this parameter (KAAAA....) is obscured or some encoding of GPU name? Why such a strange encoding?
Any time you see an encoding with lots of AAAA in it, you can bet that it's a Base64 encoding of a binary with lots of nulls in it.
>>> a=b'KAAAAAAAAAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAADgBAAAmAAAAM=='
>>> base64.b64decode(a).hex()
'2800000000000004000000000000000001800000000000000000002000000000000000e004000098000000'
(And speaking more generally, any encoding that uses both upper- and lowercase letters is quite likely Base64. For example, a SHA256 is often given in Base64 compared to hexadecimal for SHA1.)
This corresponds to this interface: https://cs.chromium.org/chromium/src/gpu/ipc/common/gpu_preferences.mojom
The wire format does not seem to be very heavily documented, so if you want to interpret this value you might be best off checking out the chromium tree and building the bindings generator. https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md
I have been trying to use the forge viewer to load somewhat large model, but it seems like that the viewer crashes after few seconds (3 - 5) of usage. (with typical Aw snap! page).
I've had no trouble with other models, but this happens on this specific model on Windows 10, Chrome.
I've tested loading in OS X, but it seem to work although it is somewhat slow.
My current best guess is that this is happening due to memory overflow in Chrome, but this is not yet certain, because the viewer crashes before I try to log the heap usage.
Is there any option that I can use for efficient model loading?
Also, is there a debug mode that allows memory tracking?
If you need the model urn, please let me know.
Thanks!
To modify the memory environment for the viewer (like iPhone), change the options parameters with memory limit values found here:
(refer to Default Memory Management section)
https://developer.autodesk.com/en/docs/viewer/v2/overview/changelog/2.17/
In particular, you can force memory management like this:
var config3d = {
memory: {
limit: 400, // in MB
debug: {
force: true
}
}
};
var viewer = new av.Viewer3D(container, config3d);
viewer.loadModel( modelUrl, {}, onSuccess, onError );
For debugging memory, try the following:
var memInfo = viewer.getMemoryInfo();
console.log(memInfo.limit); // == 400 MB
console.log(memInfo.effectiveLimit); // >= 400 MB
console.log(memInfo.loaded);
Lastly, you can open the memory manager panel extension, from the Chrome debug console, with this command...
NOP_VIEWER.loadExtension("Autodesk.Viewing.MemoryManager")
Click on the memory-chip icon, to bring up the panel (see screenshot below)...
In the memory tab, you can see many parameters relating to paged memory in order to render and network-load many meshes (mesh packs (pf) zip, sort by closest or largest mesh AABB, ignore meshes that are too few pixels on the screen, etc).
Another quick way to activate the Viewer's low-memory mode, is to trick your desktop chrome browser into thinking it's a mobile device, by activating mobile debugging. You can use this to test out mobile related memory issues.
Follow this guide: Chrome debug - Mobile mode
Hope this helps!
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.
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.