Zlece wyklonanie eksperymentu programistycznego WebGL+WebSocket

Zastanawiam się czy rozważyć aplikację webową jako alternatywna propozycje dla użytkowników , zastanawiam się ile technologia JS "wyciagnie" na sekundę ;)

zlecę wykonanie aplikacja JS , może być czysty Vanila.JS albo VUE.JS,

int w{256}
int h{512}
while(1)
{
  pobierz_z_webocket(w,h); // pobieram x*h Bajtów 
  wypelnij_teksture(w,h);    // w i h to wymiary tekstury  
  
  // np. 6 wierzchołków (x,y,u,v)  [30,100,0,0] [30,300,0,1] [130,50,0.5,0] [130,350,0.5,1] [230,100,1,0] [230,100,1,1] 
  narysuj_wierzcholki(....);   
  // tekstura jest U8 (8bitów bez znaku) , rysujemy tylko odcienie szarości, kanał A , albo RGB te same wartości  
  
  policz_i_narysuj_ilosc_klatek_na_sekunde();
}

Nie potrzebuje żadnego GUI , przycisków , styli itp., chodzi mi o przeprowadzenie eksperymentu polegającym na wyświetleniu danych i policzeniu ile wyjdzie klatek/s

Nie chce mi się tego robić, ale FPS pewnie liczony w tysiącach.

Lepiej wpisz w google "webgl performance test" albo "webgl benchmark" i będziesz miał odpowiedź. Bez sensu to pisać samemu.

Adamek Adam napisał(a):

technologia JS

Jak rozumiem z przykładowego kodu chodzi o grafikę 3D? To takie rzeczy robi się zwykle tak, że pisze się je w WebGL (zwykle używając jakiejś biblioteki typu Three.js czy Babylon.js) i w JS tworzy się obiekty, ale pod spodem przesyła się je do karty graficznej, gdzie się wykonuje duża część obliczeń. Więc de facto to przestaje być do końca tylko JS.

Zastanawiam się czy rozważyć aplikację webową jako alternatywna propozycje dla użytkowników , zastanawiam się ile technologia JS "wyciagnie" na sekundę ;)

Jeżeli patrzysz biznesowo, to nie tylko technologia jest ważna. Bo jeśliby zrobić już nie prosty benchmark, tylko faktyczną aplikację produkcyjną, to okaże się, że ważne są też:

• umiejętności danego programisty w zakresie optymalizacji i grafiki 3D. A czasem nawet drobne zmiany potrafią robić różnice. Np. powiedzmy, że mamy do wyświetlenia 1000 takich samych obiektów, to możemy wyświetlić je po kolei (co będzie wolne), a możemy użyć tzw. "instancingu" i wyświetlić wszystkie za jednym zamachem i będzie o wiele szybciej. Ale wpierw trzeba wiedzieć, że tak można.
• czas na to, żeby dokonać potrzebnych optymalizacji (napięte deadline'y sprzyjają wrzucaniu czegoś niezoptymalizowanego)
• sam design aplikacji np. wyobraźmy sobie dwie sytuacje
  • apka będzie pobierać i wyświetlać modele z bardzo dużą liczbą wierzchołków z fotorealistycznymi materiałami, a sceny będą przeciążone animacjami, dynamicznymi cieniami itp. itd. Czyli sama apka będzie wymagająca.
  • apka będzie wyświetlać prostą i w większości statyczną grafikę 3D, modele będą low-poly, animacji nie będzie wiele itp. Czyli sam design będzie miał małe wymagania.
• urządzenia, na których będzie ta apka odpalana (jak to do masowego konsumenta będzie, to nigdy nie wiesz, na czym ktoś to odpali).

I ogólnie mam wrażenie, że większość webowych apek 3D zamula z ww. powodów (słabe skille programisty, niechlujność, przeciążony design, nieprzystosowanie do słabszych urządzeń), nawet jeśli sama technologia pozwala na więcej.

dwa razy łapka w gorę za podanie nazw dwóch technologi w których można rysować 3D , jadna łapka w dół że nie chesz tego zrobić , per saldo: łapka w górę :) A tak serio to dziękuje za komentarz

ale pod spodem przesyła się je do karty graficznej, gdzie się wykonuje duża część obliczeń. Więc de facto to przestaje być do końca tylko JS

Możesz to rozwinąć ? Masz na myśli proces po stronie klienta który pobiera dane i aktualizuje pamięć tekstury i JS nie musi zajmować się duza iloscia danych
(z racji ze to nie jest w przeglądarce to moze byc soket a nie webSocket ?) ? Czy to wtedy nie jest ściśle związane z klientem i raczej nie zadziała w przeglądarce ?

Adamek Adam napisał(a):

Możesz to rozwinąć ? Masz na myśli proces po stronie klienta który pobiera dane i aktualizuje pamięć tekstury i JS nie musi zajmować się duza iloscia danych
(z racji ze to nie jest w przeglądarce to moze byc soket a nie webSocket ?) ? Czy to wtedy nie jest ściśle związane z klientem i raczej nie zadziała w przeglądarce ?

Sockety nie mają nic do tego.

Masz przeglądarkę (Chrome, Firefox itp.), która osadza silnik JSa. Jednak w przyśpieszono sprzętowej grafice JS nie liczy każdego piksela (mógłby, ale byłby to software rendering i zwykle byłoby to wolniejsze), tylko przekazuje dane o współrzędnych wierzchołków, dane macierzy czy tekstur przez WebGL do karty graficznej i dopiero tam się to liczy w pełnej krasie (można to customizować za pomocą shaderów - małych programów obsługiwanych przez kartę graficzną. WebGL obsługuje język GLSL do pisania shaderów).

I dopóki odpalasz JS w przeglądarce, to wychodzi na jedno - piszesz coś w JS i się wyświetla. Co nie zmienia tego, że nie jest to czysty JS. A pisałeś, że chcesz przetestować ile technologia JS "wyciagnie" na sekundę, a żeby to przetestować (faktycznie ocenić szybkość wywoływania JSa), to trzeba byłoby napisać jako software renderer (co by miało sens do samego benchmarku, ale już niekoniecznie na produkcję)

(z racji ze to nie jest w przeglądarce

W sensie gdzie chcesz tego JSa odpalić?
WebGL jest akurat w przeglądarkowym JSie (mimo, że samego JSa można odpalić również poza przeglądarką)

Na początek to bym się zadowolił uruchomieniem na przeglądarce chrome.

Znalazłem taki przykład gdzie WebGL używa video jako tekstury
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL

pozostaje poczytać o websocket i spróbować samemu zakasać rękawy i podmienić teksture video na strumien danych