Veliki podaci u pregledniku: zašto WebGL još nije rekao zadnju riječ
U posljednjih godinu dana pojavilo se više WebGL projekata koji ciljaju na doista velike skupove podataka. Riječ je o interaktivnim grafovima s desecima tisuća čvorova, kartama s milijunima točaka, te tehničkim vizualizacijama koje u stvarnom vremenu prikazuju telemetriju, mrežni promet ili IoT senzorske tokove. Ti primjeri pokazuju koliko se daleko može dogurati s WebGL‑om 2026., ali i gdje nastaju stvarna uska grla.
Jedan od zanimljivijih pokaznih projekata je Microsoftov msagljs demo za pregled velikih grafova. On koristi WebGL renderer i hijerarhijske tile piramide kako bi omogućio glatko zumiranje i navigaciju kroz mreže koje bi klasični DOM ili SVG potpuno slomili. Umjesto da pregledač pokušava istovremeno upravljati tisućama SVG elemenata, vizualizacija se svodi na nekoliko pažljivo pripremljenih WebGL poziva po okviru.
Ovakvi sustavi otkrivaju stvarne granice: GPU u pregledniku može iscrtati iznenađujuće mnogo geometrije, ali samo ako CPU, memorija i mrežni sloj pripreme podatke na način koji je prilagođen grafičkom pipelineu. Granica više nije samo “koliko trokuta stane u kadar”, već “koliko podataka možemo u svakom trenutku učinkovito dostaviti GPU‑u”.
Gdje su stvarna uska grla: CPU, memorija i mreža
Iskustvo iz recentnih WebGL projekata jasno pokazuje da WebGL API sam po sebi rijetko bude primarno usko grlo. Veći problemi javljaju se u:
- CPU pripremi podataka – dekodiranje, filtriranje, grupiranje i preraspodjela velikih tablica ili grafova prije slanja na GPU;
- rasporedu memorije – neefikasne strukture podataka, previše malih alokacija, fragmentacija i nepotrebne kopije;
- mrežnom prijenosu – učitavanje gigabajta podataka preko HTTP‑a ili WebSocketa bez ikakvog streaminga ili kompresije.
Tipičan antipattern izgleda ovako: aplikacija prvo učita kompletan skup podataka (npr. milijun čvorova grafa) u JavaScript objekte, zatim ih više puta preradi, tek onda prebaci u tipizirane nizove, i na kraju ih šalje u WebGL buffere. U tom scenariju GPU većinu vremena čeka, dok CPU i GC (garbage collector) bore bitku s gomilom objekata.
Moderni projekti zato uvode strožu disciplinu nad podacima. Umjesto razbacanih JavaScript objekata koriste se tipizirani nizovi i binarni formati. Dekodiranje se premješta u Web Workere kako bi se rasteretio glavni thread, a podaci se organiziraju u blokove koji se mogu neovisno učitavati i odbacivati. Time se CPU svodi na ulogu “dirigenta” koji orkestrira tok podataka prema GPU‑u, umjesto da bude usko grlo.
Tile piramide, LOD i streaming: obrasci za milijune elemenata
Novi WebGL preglednici velikih scena gotovo uvijek primjenjuju tri ključna obrasca: tile piramide, LOD (Level of Detail) i streaming pristup.
Tile piramide za grafove, karte i oblake točaka
Tile piramida je hijerarhijska struktura u kojoj se podaci dijele na pločice (tileove) različitih razina. Svaka razina predstavlja isti prostor, ali s različitom gustoćom ili agregacijom podataka. Za vizualizaciju grafova to može značiti:
- na najvišoj razini – nekoliko “superčvorova” koji predstavljaju cijele klastere;
- na srednjim razinama – ključni čvorovi i veze unutar klastera;
- na najnižoj razini – svi pojedinačni čvorovi i bridovi.
Preglednik u svakom trenutku učitava samo one tileove koji su u vidnom polju i na razini detalja koja odgovara trenutnom zumu. Ako se korisnik kreće kartom ili grafom, stari tileovi se odbacuju, a novi se strimaju s poslužitelja ili iz lokalnog cachea.
LOD sheme za stabilan FPS
LOD sheme omogućuju da se ista scena prikazuje s različitim brojem trokuta ili točaka, ovisno o udaljenosti od kamere i važnosti objekta. To je standard u gamingu, ali u WebGL vizualizacijama velikih podataka dobiva novu ulogu:
- udaljeni dijelovi grafa mogu se prikazati kao jednostavne točke ili male spritove;
- detaljni oblici i teksture učitavaju se tek kad korisnik dovoljno zumira;
- agregirani podaci (npr. “broj događaja u regiji”) zamjenjuju pojedinačne zapise dok je pogled širok.
Rezultat je stabilniji FPS i bolji frame pacing, jer GPU dobiva predvidljiviji broj primitiva po okviru, umjesto naglih skokova kada se u kadar odjednom “ulije” previše geometrije.
Streaming umjesto monolitnih scena
Umjesto da se cijela scena učita u jednom potezu, moderni WebGL sustavi tretiraju sve kao tok podataka. Podaci dolaze u paketima, postupno se dekodiraju i šalju u GPU buffere, a stari se blokovi pravovremeno uklanjaju. Ovaj pristup je već standard u WebGPU svijetu, ali se jednako dobro primjenjuje i na WebGL.
Primjer iz prakse: vizualizacija vremenskih serija iz IoT senzora. Umjesto da se prikupi cjelogodišnji zapis i nacrta kao jedna golema linija, sustav stalno strima nove uzorke, dok se stari segmenti arhiviraju ili prikazuju u jako sažetom obliku. GPU u svakom trenutku radi s relativno malim, ali reprezentativnim podskupom podataka.
Optimiranje izvan shadera: dizajn podatkovnog modela i API‑ja
Za WebGL developere 2026. optimizacija više ne počinje u shaderima, nego u dizajnu podatkovnog modela i API‑ja. Ključna pitanja postaju:
- kako strukturirati podatke da omogućimo parcijalno učitavanje;
- kako agresivno i sigurno odbacivati nepotreban sadržaj iz memorije;
- kako minimizirati broj draw callova po okviru;
- kako organizirati atribute da se maksimalno iskoristi GPU cache.
U praksi to znači da se već u fazi backend API‑ja razmišlja u terminima tileova, LOD razina i binarnih blokova. REST ili gRPC endpointi ne vraćaju više “cijeli graf”, nego “tile (x, y, zoom)” ili “segment vremenske serije”. WebSocket gatewayi strimaju delta‑pakete, a edge uređaji (npr. lokalni gateway za senzore) rade osnovnu agregaciju prije slanja u preglednik.
Instanciranje, batchevanje i teksture kao spremnik atributa
Kad govorimo o samom WebGL‑u, tri tehnike se nameću kao nužne za velike scene: instanciranje, batchevanje geometrije i korištenje tekstura kao spremnika atributa.
Instanciranje za tisuće sličnih elemenata
Instanciranje omogućuje da jedan geometrijski model (npr. točka, kvadrat ili jednostavni marker) bude nacrtan tisuće puta s različitim transformacijama i bojama, uz minimalan broj draw callova. To je idealno za:
- čvorove u grafu;
- točke u oblaku točaka;
- markere na karti ili tehničkoj shemi.
Umjesto 10 000 draw callova, sustav šalje jedan ili nekoliko instanced poziva, a varijabilni podaci (pozicija, boja, veličina) dolaze kroz dodatne buffere ili teksture.
Batchevanje geometrije za manje overhead
Batchevanje znači spajanje više objekata u jedan veći buffer kako bi se smanjio broj poziva prema GPU‑u. U vizualizacijama velikih podataka to može biti grupiranje čvorova po klasterima, segmentima grafa ili prostornim blokovima. Cilj je postići da cijela scena, bez obzira koliko logičkih objekata ima, završi u nekoliko stotina draw callova po okviru.
Dobro projektiran sustav tako može korisniku ostaviti dojam “nebrojenih” objekata u sceni, dok WebGL zapravo crta relativno mali broj batcheva, svaki pažljivo optimiran za GPU cache i memorijski pristup.
Teksture kao kompaktni spremnik atributa
Umjesto da se svi atributi (npr. dodatni metrički podaci o čvoru) drže u klasičnim vertex bufferima, sve se češće koriste teksture kao podatkovni spremnici. Svaki piksel teksture sadrži više numeričkih vrijednosti, koje shader može pročitati prema indeksu instance ili čvora.
Ovaj pristup olakšava:
- dinamičko ažuriranje podataka bez rekreiranja cijelog vertex buffera;
- kompaktno pakiranje više atributa u jedan GPU resurs;
- korištenje istih podataka u više rendering passova (npr. za selekciju, heatmap sloj, highlight efekate).
Zašto WebGL 2026. i dalje ima smisla uz WebGPU
Iako se WebGPU sve snažnije probija, mnogi novi projekti i dalje zadržavaju WebGL renderer kao primarnu ili barem početnu opciju. Razlozi su vrlo pragmatični:
- stabilnost i podrška – WebGL je podržan u gotovo svim modernim preglednicima, uključujući starije uređaje i embedded sustave;
- zreli alati – postojeći debug alati, biblioteke i enginei (npr. Three.js) dobro su ispitani;
- niži rizik – za poslovne i enterprise vizualizacije često je važnija pouzdanost od apsolutnog maksimuma performansi.
Istovremeno, timovi koji razdvoje logiku scene od konkretnog renderera mogu kasnije relativno lako dodati WebGPU backend. Ako se od početka uvede koncept apstraktnih resursa (bufferi, teksture, materijali, pipeline konfiguracije), prijelaz na WebGPU postaje evolucijski korak, a ne potpuna migracija.
Primjer arhitekture iz prakse:
- gornji sloj – scena, graf, senzorski tokovi, poslovna logika;
- srednji sloj – apstraktni resursi i komande (kreiraj buffer, ažuriraj teksturu, pokreni rendering pass);
- donji sloj – konkretna implementacija za WebGL ili WebGPU.
Na taj način ista vizualizacijska platforma može istovremeno nuditi WebGL renderer za maksimalnu kompatibilnost i WebGPU renderer za korisnike s novijim preglednicima i jačim GPU‑ima.
Od broja trokuta do dizajna podatkovnog toka
Recentni showcase projekti za prikaz velikih skupova podataka u pregledniku pomiču fokus s pitanja “koliko trokuta možemo iscrtati” na pitanje “kako strukturirati podatke da GPU uopće dobije smislen zadatak”.
Za developere to znači promjenu načina razmišljanja:
- scene više nisu statični modeli, nego tokovi podataka koji stalno pristižu, mijenjaju se i nestaju;
- optimizacija kreće od dizajna API‑ja, formata i protokola, tek onda prelazi na shadere i pipeline;
- edge uređaji, gatewayi i poslužitelji igraju ključnu ulogu u filtriranju i agregaciji prije nego što išta dođe do preglednika.
U tom smislu WebGL 2026. služi kao stabilna, dobro poznata platforma na kojoj se ispituju arhitektonske ideje koje će se kasnije preslikati i na WebGPU. Tko danas u WebGL‑u nauči projektirati scene kao tokove podataka, a ne kao statične modele, spreman je za sljedeću generaciju 3D web tehnologija bez radikalnih promjena u načinu razmišljanja.
Granice GPU‑a u pregledniku tako se pomiču manje kroz nove API‑je, a više kroz pametniji dizajn podataka, protokola i pipelinea. WebGL ostaje dokaz da se i s “danas već klasičnom” tehnologijom može isporučiti vizualizacija milijuna elemenata – pod uvjetom da cijeli sustav, od senzora do shadera, radi kao jedna dobro orkestrirana cjelina.
