Glavni UI thread kao stvarno usko grlo WebGL aplikacija
Najnoviji WebGL i WebGPU showcase projekti iz 2026. jasno pokazuju pomak u percepciji uskih grla. Problem više nije samo sirova GPU snaga. Ključno ograničenje postaje arhitektura web runtimea. Event-loop, layout, input, JavaScript logika i WebGL rendering često su i dalje stisnuti u jedan glavni UI thread preglednika.
U teoriji, moderni GPU lako podnosi desetke tisuća trokuta, kompleksne shader programe i post-processing lance. U praksi, svaki frame mora proći kroz isti pipeline: evente miša i tipkovnice, mrežne callbackove, framework logiku (React, Vue, Svelte), layout i style recalculation, pa tek onda WebGL draw pozive. Čim jedan segment „zapne“, cijeli frame kasni i FPS pada.
Showcase projekti koji ciljaju 60 FPS ili 120 FPS zato sve češće naglašavaju: WebGL performanse ovise manje o „brzini GPU-a“, a više o disciplini u korištenju glavnog threada. To se posebno vidi u interaktivnim vizualizacijama, 3D konfiguratorima proizvoda i web igrama koje kombiniraju kompleksan UI i WebGL scenu.
Kako izgledaju tipične WebGL/Three.js scene 2026.
Tipičan moderni WebGL ili Three.js projekt u 2026. nije samo „lijepi shader na platnu“. Uobičajena kombinacija uključuje:
- PBR materijale s više teksturnih mapa (albedo, normal, roughness, metalness, AO)
- Post-processing lance (bloom, tone mapping, SSAO, DOF)
- Interaktivnu fiziku ili barem jednostavne sudare
- DOM/UI sloj izgrađen u Reactu, Vueu ili Svelteu
- Mrežnu komunikaciju u realnom vremenu (WebSocket, WebRTC)
U takvom setupu i relativno jednostavna scena može početi trzati. Dovoljno je da se u istom frameu dogodi skupa serijalizacija podataka, neoptimizirani state update u SPA frameworku ili layout thrash zbog čestih promjena stilova.
Primjer iz prakse: 3D konfigurator automobila u pregledniku. Na platnu se renderira model s PBR materijalima, refleksijama i shadow mapama. Istovremeno, React UI prikazuje izbornike boja, paketa opreme i cijena, s animiranim tranzicijama. Kada korisnik promijeni konfiguraciju, aplikacija šalje mrežni zahtjev, parsira odgovor, ažurira globalni state i rerendera dio DOM-a. Ako se sve to dogodi unutar jednog framea, WebGL render-loop na istom threadu dobije manje vremena. Posljedica je pad s 60 FPS na 30–40 FPS, vidljiv kroz trzaje i loš frame pacing.
Zašto svaki JS „spike“ direktno pogađa FPS
Glavni UI thread u pregledniku funkcionira kao serijski event-loop. Sve što se izvršava na njemu dijeli isti vremenski budžet po frameu. Za 60 FPS taj budžet iznosi oko 16,6 ms, za 120 FPS oko 8,3 ms. Ako jedan JavaScript task zauzme 10–12 ms, za layout, painting i WebGL rendering ostaje vrlo malo vremena.
Showcase projekti iz 2026. često objavljuju profilere i timeline snimke. Na njima se jasno vidi obrazac:
- kratki burst React rendera ili složenog state managementa
- GC pauza zbog mnogih kratkotrajnih alokacija
- layout i style recalculation nakon promjena u DOM-u
- WebGL render koji se „stisne“ na kraj framea, ponekad i u sljedeći frame
Rezultat nije samo manji prosječni FPS. Još je važniji loš frame pacing. Korisnik osjeća neujednačene frameove, s povremenim „štucanjima“, iako prosječni FPS možda izgleda prihvatljivo. To je razlog zašto iskusni WebGL developeri danas profiliraju event-loop jednako ozbiljno kao i GPU pipeline.
Web Workers kao nužan alat: tanak render-loop na glavnom threadu
Kako bi rasteretili glavni UI thread, showcase projekti sve češće agresivno koriste Web Workers. Ideja je jednostavna: sve što ne mora dirati DOM ili WebGL kontekst seli se u radne threadove.
Tipični zadaci za Web Workers
- Priprema i kompresija geometrije (generiranje LOD-ova, spajanje meshova)
- Parsiranje i dekodiranje formata (glTF, draco, basis, custom binarni formati)
- Simulacija fizike i particles sustava
- Streaming i dekompresija podataka s mreže
- Generiranje proceduralnih tekstura ili terena
Glavni thread tada dobiva već pripremljene podatke, često u obliku transferable ArrayBuffer objekata. WebGL kontekst se koristi isključivo za kreiranje i ažuriranje buffera, tekstura i draw callove. Render-loop postaje što tanji: primanje već spakiranih uniform podataka, priprema minimalnog broja draw poziva i završni rendering pass.
Jedan showcase projekt arhitekturu je opisao formulom: „glavni thread = input + finalni draw“. Sve ostalo: fizika, AI, priprema instanci, pa čak i dio game logike, živi u workerima. Takav pristup ne uklanja sva ograničenja, ali dramatično smanjuje rizik da pojedina JS operacija blokira rendering.
Batchiranje, instanciranje i realni dobici u odnosu na shader trikove
Još jedna lekcija iz 2026. jest da „egzotični shader trikovi“ često donose manji dobitak od dosadnih, ali ključnih optimizacija na razini draw callova. Showcase projekti koji su detaljno mjerili performanse izvještavaju:
- Batchiranje draw callova (spajanje više objekata u jedan mesh ili korištenje texture atlasa) smanjuje CPU overhead i vrijeme provedeno u driveru.
- Instanciranje (gl.drawArraysInstanced / gl.drawElementsInstanced) omogućuje renderiranje stotina ili tisuća istih objekata uz minimalne dodatne troškove na glavnom threadu.
- Unaprijed pripremljeni uniform buffer paketi i strukture podataka smanjuju broj pojedinačnih gl.uniform poziva po frameu.
U praksi, prelazak s desetaka ili stotina draw callova na nekoliko batcheva donosi više FPS-a nego mikro-optimiziranje fragment shadera. Razlog je jednostavan: svaki draw call nosi CPU overhead, a taj overhead živi na glavnom UI threadu. Manje draw callova znači više „prozračnog“ vremena za ostatak pipelinea.
Kada UI prelazi u WebGL platno umjesto DOM-a
Zanimljiv trend u nekim showcase projektima je potpuno napuštanje DOM-a za kompleksne UI slojeve. Umjesto kombinacije WebGL platna i HTML elemenata, cijeli UI se crta unutar WebGL ili WebGPU konteksta. Tipični motivi su:
- Eliminacija layout i style recalculation faza po frameu
- Potpuna kontrola nad rendering pipelineom i z-orderom elemenata
- Jedinstven coordinate space i input sustav (hit testovi u 3D/2D prostoru scene)
Ovakav pristup nije trivijalan. Zahtijeva implementaciju vlastitih UI komponenti, font rendering sustava, fokus i navigaciju tipkovnicom, te prilagodbu pristupačnosti. No za projekte koji ciljaju na maksimalnu fluidnost animacija, prelazak kompletnog UI-ja u WebGL platno uklanja cijelu klasu problema vezanih uz DOM performanse.
Primjer je interaktivni storytelling projekt u kojem se tekst, gumbi, slideri i overlay grafika renderiraju kao teksture i geometrija unutar istog scene grapha kao i 3D modeli. Layout se računa u vlastitom engineu, dok je DOM sveden na minimalni overlay za osnovne kontrole i analitiku.
WebGL naspram WebGPU: granica se pomiče prema paralelizaciji
Kako WebGPU sazrijeva, pitanje „kada prijeći na WebGPU?“ sve se češće postavlja. Showcase projekti iz 2026. sugeriraju da se praktična granica ne povlači samo po pitanju rasterizera, već prvenstveno po pitanju paralelizacije i compute mogućnosti.
Kada je WebGL još uvijek dovoljan
WebGL i dalje sasvim dobro pokriva:
- klasične 3D scene s umjerenim brojem dinamičkih svjetala
- standardne PBR materijale i jednostavnije post-processing lance
- interaktivne konfiguratore, vizualizacije podataka i edukativne projekte
- igre koje ne traže masivne particles ili napredne simulacije
U tim slučajevima, najveći dobitak ne dolazi prelaskom na WebGPU, već disciplinom u korištenju glavnog threada, workerima i optimizacijom draw callova.
Kada WebGPU postaje nužan
WebGPU se pokazuje ključnim u projektima koji trebaju:
- masivan broj dinamičkih svjetala uz kompleksne SDF/PBR efekte
- napredne particles sustave, boids simulacije i fluid dinamiku
- compute shadere za obradu velikih skupova podataka ili GPGPU zadatke
- detaljnu kontrolu nad memory layoutom i pipeline konfiguracijom
Takvi projekti često kombiniraju pristupe: WebGPU se koristi za compute i najzahtjevnije efekte, dok WebGL ostaje kao „baseline renderer“ za preglednike bez potpune WebGPU podrške. Time WebGL u 2026. postaje konzervativni, ali i dalje ključni sloj kompatibilnosti.
Što ovo znači za WebGL developere u praksi
Za WebGL developere ove spoznaje nose vrlo konkretne implikacije za arhitekturu projekata.
1. Profiliranje event-loopa jednako je važno kao i GPU profiling
Umjesto fokusiranja isključivo na GPU statistike, potrebno je redovito koristiti alate poput Chrome Performance panela, Firefox Profiler ili Lighthouse izvještaja. Cilj je otkriti:
- dijaloge koji blokiraju glavni thread
- GC pauze zbog prekomjernih alokacija
- layout thrash uzrokovan čestim DOM promjenama
- duge JavaScript callbackove koji se izvršavaju u jednom komadu
Tek kada je event-loop „čist“, ima smisla duboko optimizirati shadere.
2. Dizajn od početka računa na offload posla u workere ili na server
Umjesto kasnijeg „krpanja“, arhitektura bi od početka trebala predvidjeti:
- jasne granice između logike koja smije biti na glavnom threadu i one koja se seli u workere
- formate podataka optimizirane za prijenos između threadova (minimalno kopiranje, transferables)
- mogućnost delegiranja težih izračuna na server gdje je to opravdano
Tako se izbjegava situacija u kojoj projekt postane teško refaktorirati tek kada se pojave problemi s FPS-om.
3. Migracija na WebGPU ima smisla tek nakon iscrpljivanja WebGL optimizacija
Showcase projekti pokazuju da prelazak na WebGPU neće magično riješiti probleme ako je glavni thread i dalje zagušen lošom JavaScript i DOM arhitekturom. Prije razmišljanja o migraciji, treba jasno odgovoriti na nekoliko pitanja:
- Je li bottleneck stvarno u GPU rasterizeru, ili u CPU dijelu pipelinea?
- Jesu li batchiranje, instanciranje i rad s workerima već maksimalno iskorišteni?
- Je li scena razumno organizirana, ili postoji previše malih objekata i draw callova?
Tek kada su osnovne WebGL optimizacije iscrpljene, a analiza pokaže da su compute zadaci i paralelizacija stvarni problem, prelazak na WebGPU ima puni smisao. U suprotnom, postoji rizik da se složenost poveća, a stvarni problemi ostanu isti.
Zaključak: WebGL kao optimizirani baseline u eri WebGPU-a
Najnoviji showcase projekti iz 2026. jasno potvrđuju: WebGL nije „mrtav“, ali njegova uloga se mijenja. Postaje optimizirani baseline renderer koji mora funkcionirati u strogo ograničenom prostoru glavnog UI threada. U tom kontekstu, uspjeh projekata ovisi manje o spektakularnim shaderima, a više o pažljivoj arhitekturi, profiliranju event-loopa i discipliniranom korištenju JavaScripta i DOM-a.
Za developere koji to prihvate i svoje projekte dizajniraju s jasnim fokusom na glavni thread, WebGL će još godinama ostati dovoljno snažan za većinu produkcijskih slučajeva. Za one koji trebaju više, WebGPU stoji kao nadogradnja – ali tek nakon što su stvarna ograničenja jasno identificirana i adresirana.
