The polygon count of your heaviest model should decide the library, not the other way around.
If you are building augmented reality for the web, the rendering library is one of the first decisions you make, and one of the hardest to reverse later. Switching means rebuilding the content pipeline.
The study behind this comparison examined that choice directly, in an HTML based AR application built on AR.js, a JavaScript library that runs augmented reality in the browser without asking users to install a plugin.
The library covers three common styles of augmented reality: marker based, where a printed or on screen bookmark triggers the content; image based, where a picture acts as the anchor; and location based, where the scene is tied to coordinates. It also supports visual and audio effects alongside the 3D content.
That breadth is convenient, because it means the rendering decision is not tied to one AR mode. The same application can mix modes and still share a rendering path.
The study's own findings give one clear answer. Both approaches handled low and medium polygon models. Only at high polygon counts did WebGL fall away, while GLSL held its ground near native performance.
The caveat matters as much as the result. This was a rendering benchmark, not a study of a finished application, and actual performance also depends on the device and the browser running it. Use the polygon count of your real content as the deciding input, not the label on the library.
Hamzaturrazak et al. (2023). Performance Analysis of 3D Rendering Method on Web-Based Augmented Reality Application Using WebGL and OpenGL Shading Language. Proceedings of the 8th International Conference on Sustainable Information Engineering and Technology.
