twgl.js
twgl.js copied to clipboard
greggman
stackgl? speed on mobile vs threejs?
-
i've noticed the fps of twgl demos are higher compared to lots of threejs demos (on my moto g4 smartphone). Besides twgl not doing any scenegraph-management, are there any other reasons which could explain this?
-
is this library somewhat compatible with stackgl?
-
any suggestion for dev tools? (dat.gui, show fps etc)
Three.js is a somewhat high level monolithic framework which abstracts away most of the underlying webgl api and presents developers, as you mentioned, with a scene graph, camera and lighting system and material based object definition. In fact webgl isn't a requirement for three at all, since it can also leverage canvas and css rendering options for example. As such the codebase for three is somewhat huge, even for relatively simple projects.
stack.gl can be thought of as a more modular set of components that can be bolted together to create a more targetted feature set based on your project's requirements. The resulting builds are usually a bit leaner than three.js, but you have to do a bit more legwork to get things up and running. There is still a cost associated with components being higher level abstractions.
With both these options a developer won't have to write any shader code to get something done ( three.js has large super-shaders that provide lots of functionality by default, stack.gl has modular shaders compiled with glslify )
By contrast twgl is more or less a thin helper library that simplifies a lot of the verbose boilerplate code that you encounter when working directly with the webgl api. Twgl expects you to write the application, shader code and rendering logic yourself. There is very little wastage here beyond the raw webgl browser api ( but more costly in developer time and knowledge )
If you want to see an example of the difference I suggest you install a webgl browser debug tool like spectre.js and profile the difference in state between a similar three.js and twgl.js example project. You will most likely see a significantly smaller number of instructions being sent to the GPU in the latter.
You may not notice this too much on a desktop website ( on a machine with a decent graphics card for example ), but for mobile development, where phone GPUs tend to have limited bandwidth and memory capacity you will see a larger impact from sending lots of data and performing unnecessary draw calls.
It's worth re-iterating what @greggman says the readme:
"If you want to get stuff done use three.js. If you want to do stuff low-level with WebGL consider using TWGL"
Thank you for all the info & suggestions.
On Wed, Jun 19, 2019 at 11:57 AM Joe Fox [email protected] wrote:
Three.js is a somewhat high level monolithic framework which abstracts away most of the underlying webgl api and presents developers, as you mentioned, with a scene graph, camera and lighting system and material based object definition. In fact webgl isn't a requirement for three at all, since it can also leverage canvas and css rendering options for example. As such the codebase for three is somewhat huge, even for relatively simple projects.
stack.gl can be thought of as a more modular set of components that can be bolted together to create a more targetted feature set based on your project's requirements. The resulting builds are usually a bit leaner than three.js, but you have to do a bit more legwork to get things up and running. There is still a cost associated with components being higher level abstractions. With both these options a developer won't have to write any shader code to get something done ( three.js has large super-shaders that provide lots of functionality by default, stack.gl has modular shaders compiled with glslify )
By contrast twgl is more or less a thin helper library that simplifies a lot of the verbose boilerplate code that you encounter when working directly with the webgl api. Twgl expects you to write the application, shader code and rendering logic yourself. There is very little wastage here compared to raw the raw webgl browser api ( but more costly in developer time and knowledge )
If you want to see an example of the difference I suggest you install a webgl browser debug tool like spectre.js and profile the difference in state between a similar three.js and twgl.js example project. You will most likely see a significantly smaller number of instructions being sent to the GPU in the latter.
It's worth re-iterating what @greggman https://github.com/greggman says the readme:
"If you want to get stuff done use three.js. If you want to do stuff low-level with WebGL consider using TWGL"
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/greggman/twgl.js/issues/130?email_source=notifications&email_token=AABL6ZGTXXFQK6YRMLTTYODP3H7HJA5CNFSM4HZFLPK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYBLEEA#issuecomment-503493136, or mute the thread https://github.com/notifications/unsubscribe-auth/AABL6ZD2W5OOB3OGUSBGKBDP3H7HJANCNFSM4HZFLPKQ .
--
Léon
/COMPANY
/WEBSITE
/MOBILE
/LOCATION
/COMPANYNR.
/TAGS
van Kammen
2WA CONSULTANCY
2wa.isvery.ninja/hello
+31 6 13499604
Netherlands, Drachten.
08124656
Web & New Media
consultancy
driven by open source,
Google tech &
a teaspoon of javascript.
https://www.linkedin.com/in/leonvankammen https://github.com/coderofsalvation
99% of the three.js samples set the canvas resolution to match display 1 to 1. For most phones that's 4x to 6x the number of pixels to render vs the twgl examples which just leave the resolution at CSS size. That is likely the biggest slow down and I'd personally argue they shouldn't be doing that by default as it's the wrong choice for 99% of all apps IMO. People generally can't tell the difference. The browser bilinear filters and/or antialiases the canvas anyway so all they do is make phones run slow and low-powered but HI-DPI devices like a macbook run like crap on their demos.
In my experience at least, running at CSS resolution on retina is noticeably "soft" - but you can probably get away with somewhere midway between a scale factor of 1 and the device pixel ratio - I guess it depends on the use case
I disagree . I think it's only blurry with line drawing and other high contrast stuff and even then 99% of users wouldn't care. only gpu geeks. the rest would rather have a responsive app
I disagree . I think it's only blurry with line drawing and other high contrast stuff and even then 99% of users wouldn't care. only gpu geeks. the rest would rather have a responsive app
naturally if it's impacting performance or killing the battery it's definitely not something you should be doing :) I guess my use case isn't "normal" though, as it overlays transparent webgl layers on underlying canvas, which makes the resolution contrast very apparent.
to add . you didn't seem to notice the twgl examples are lower res or you'd have guessed that's why they run faster 😉
to add . you didn't seem to notice the twgl examples are lower res or you'd have guessed that's why they run faster wink
I just grabbed an office ipad pro and checked your examples - definitely agree that for full page apps, device resoluton would be a complete waste of time. It's only slightly noticeably soft on item-list and text demos
thx. Interesting thoughts. To me (coming from a perspective of selling ideas to clients), the lowest common denominator (mobile specs) is what counts most. these days webpages are visited mostly on mobile). It also has been the reasons why I've been watching THREEjs on the sideline for now. In an ideal world the canvas resolution could be scaled in realtime (based on fps performance). This will happen once the pope will dance a waltz with putin.
For all kinds of reasons the canvas cannot scale automatically. Something like that has to be up to the app itself.
See: https://github.com/greggman/twgl.js/pull/100
On the other hand, here's an app that tries to scale to the user's power. It doesn't change the resolution of the canvas. It just draws more or less.
https://webglsamples.org/field/field.html
Of course each person wants their own tradeoffs that's why nearly all PC games let the user choose what they want.
99% of users wouldn't care
<_<, actually @2x @3x resolution pretty noticeable.
PIXI.js, ClayGL, REGL, p5.js uses devicePixelRatio as a default scale parameter. Yes, sometimes it’s not exactly equal to the physical pixels in some browsers, but much better than blurry 1x. Also we don't have any device with more than 4x: https://material.io/resources/devices/