WebGL optimization in navigation.

%3CLINGO-SUB%20id%3D%22lingo-sub-1116274%22%20slang%3D%22en-US%22%3EWebGL%20optimization%20in%20navigation.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1116274%22%20slang%3D%22en-US%22%3E%3CP%3EHello!%26nbsp%3BAfter%20the%20end%20of%20support%20for%20unity%20apis%2C%20one%20feature%20that%20has%20been%20adopted%20by%20many%20is%20WebGL%20for%20both%20games%20and%20websites%2C%20but%20it%20performs%20very%20poorly%20in%20most%20browsers%2C%20a%20way%20I%20think%20could%20solve%20such%20a%20problem%2C%20would%20be%20putting%20WebGL%20as%20a%20separate%20process%20in%20the%20Microsoft%20Edge%20process%20tree%20and%20giving%20high%20priority%20to%20the%20process%2C%20making%20it%20run%20more%20powerfully.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1116428%22%20slang%3D%22en-US%22%3ERe%3A%20WebGL%20optimization%20in%20navigation.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1116428%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F316260%22%20target%3D%22_blank%22%3E%40LucasS-10%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUnity%20no%20longer%20depends%20on%20a%20plugin%2C%20but%20is%20still%20used%20on%20the%20web.%3C%2FP%3E%3CP%3Esome%20internal%20parts%20of%20the%20browser%20are%20already%20on%20their%20separate%20process%20(like%20the%20compositor%20thread)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ethe%20host%20system%20or%20the%20graphics%20API%20ANGLE%20is%20using%20also%20affects%20WebGL's%20performance.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20is%20a%20overhead%20of%20communicating%20between%20JavaScript%20and%20WebGL%2C%20too%3B%20with%20the%20lack%20of%20SIMD%20or%20other%20low-level%20features.%20(Unless%20you%20use%20something%20like%20WebAssembly.)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhile%20the%20performance%20varies%20greatly%20due%20to%20code%20quality%20or%20optimizations%2C%20considering%20that%20the%20Shaders%20are%20already%20running%20on%20the%20GPU%20it%20should%20be%20fast%20enough%20for%20a%20Web%20app.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20WebGL%20Aims%20to%20be%20safe%20as%20well%20(sandboxes%2C%20sanity%20checks%2C%20etc)%20so%20theres%20a%20bit%20of%20speed%20trade-off.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWith%20everything%20mentioned%20above%2C%20WebGL%20should%20still%20be%20very%20fast%20especially%20for%203D%20Workloads%2C%20you%20can%20expect%2030fps%20even%20on%20a%20low%20end%20mobile%20device%20at%20worst.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20it%20really%20performs%20that%20poor%20there%20might%20be%20another%20problem%2C%20maybe%20GPU%20acceleration%20is%20disabled%3F%3C%2FP%3E%3CP%3E%5B%20you%20can%20find%20more%20debug%20info%20in%20edge%3A%2F%2Fgpu%20%5D%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CFONT%20size%3D%221%202%203%204%205%206%207%22%3EAs%20a%20side%20note%26nbsp%3B%3CSPAN%20class%3D%22commtext%20c00%22%3EWebGL%20(1%20or%202)%20doesn't%20support%20compute%20Shaders%2C%20WebGL%202.0%20Compute%20API%20which%20is%20based%20on%20OpenGL%20ES%203.1%20solves%20this%20and%20allows%20you%20to%20perform%20GPGPU%20tasks%2C%20such%20as%20direct%20read%2Fwrites%20operations%20on%20the%20GPU%20that%20scales%20very%20well%20with%20heavier%20workloads.%20Although%20I'd%20say%20waiting%20for%20WebGPU%20to%20stabilize%20is%20better.%3C%2FSPAN%3E%3C%2FFONT%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Occasional Contributor

Hello! After the end of support for unity apis, one feature that has been adopted by many is WebGL for both games and websites, but it performs very poorly in most browsers, a way I think could solve such a problem, would be putting WebGL as a separate process in the Microsoft Edge process tree and giving high priority to the process, making it run more powerfully. 

1 Reply
Highlighted

@LucasS-10 

 

Unity no longer depends on a plugin, but is still used on the web.

some internal parts of the browser are already on their separate process (like the compositor thread)

 

the host system or the graphics API ANGLE is using also affects WebGL's performance.

 

There is a overhead of communicating between JavaScript and WebGL, too; with the lack of SIMD or other low-level features. (Unless you use something like WebAssembly.)

 

While the performance varies greatly due to code quality or optimizations, considering that the Shaders are already running on the GPU it should be fast enough for a Web app.

 

And WebGL Aims to be safe as well (sandboxes, sanity checks, etc) so theres a bit of speed trade-off.

 

With everything mentioned above, WebGL should still be very fast especially for 3D Workloads, you can expect 30fps even on a low end mobile device at worst.

 

 

If it really performs that poor there might be another problem, maybe GPU acceleration is disabled?

[ you can find more debug info in edge://gpu ]

 

 

As a side note WebGL (1 or 2) doesn't support compute Shaders, WebGL 2.0 Compute API which is based on OpenGL ES 3.1 solves this and allows you to perform GPGPU tasks, such as direct read/writes operations on the GPU that scales very well with heavier workloads. Although I'd say waiting for WebGPU to stabilize is better.