Czy jest jakiś powód, aby używać WebGL zamiast 2D Canvas w grach / aplikacjach 2D?


114

Czy jest jakiś powód, poza wydajnością, by używać WebGL zamiast 2D-Canvas dla grach / aplikacjach 2D ?

Innymi słowy, jakie funkcjonalności 2D oferuje WebGL, których nie da się łatwo osiągnąć za pomocą 2D-Canvas?


5
Przy okazji: chociaż nie możesz używać kontekstowego API 2D i 3D na tym samym płótnie, nadal możesz je łączyć, używając wielu płócien. WebGL może używać płótna 2d jako tekstur, a płótna 2d może używać płótna WebGL jako źródła drawImage.
Philipp,

Odpowiedzi:


85

Patrząc na to pytanie z innej strony: w
jaki sposób programista wybiera jedną technologię, a nie inną?

  • integruje się lepiej z już zbudowanym systemem
  • jest łatwiejszy w użyciu
  • jest szybszy
  • ma większe możliwości lub lepiej odpowiada ich potrzebom
  • koszt
  • bardziej niezależny od platformy

Dlatego omówię różnice między interfejsami API kanwy i interfejsu API webGL w odniesieniu do tych cech.


Zarówno płótno, jak i webGL są interfejsami API JavaScript. Są prawie takie same, jeśli chodzi o integrację (wiązanie). Oba są obsługiwane przez wiele bibliotek, które mogą przyspieszyć kodowanie. Różne biblioteki oferują różne sposoby organizowania kodu, więc wybór biblioteki decyduje o strukturze twoich rysunkowych interfejsów API, ale nadal jest to prawie to samo (jak reszta kodu wiąże się z nim). Jeśli używasz biblioteki, łatwość pisania kodu zależy od samej biblioteki.

Jeśli piszesz kod od zera, interfejs API kanwy jest znacznie łatwiejszy do nauczenia i zrozumienia. Wymaga minimalnej wiedzy matematycznej, a programowanie jest szybkie i proste.

Praca z interfejsem API WebGL wymaga dużych umiejętności matematycznych i pełnego zrozumienia potoku renderowania. Osoby z tymi umiejętnościami są trudniejsze do znalezienia, produkcja przebiega wolniej (ze względu na rozmiar i złożoność takiej bazy kodu), a co za tym idzie kosztuje więcej.

WebGL jest szybszy i ma więcej możliwości. Nie ma co do tego wątpliwości. Jest to natywny interfejs API 3D, który zapewnia pełny dostęp do potoku renderowania, kod i efekty są wykonywane szybciej i są bardziej „modyfikowalne”. Dzięki webGL naprawdę nie ma ograniczeń.

Zarówno płótno, jak i webGL to gadżety HTML5. Zwykle urządzenia obsługujące jedno będą obsługiwać, a drugie.

Więc by podsumować:

  • łączenie kodu API rysowania z resztą (integracja): podobnie
  • łatwość użycia:
    • (z biblioteką) canvas = webGL
    • (od podstaw) webGL << canvas
  • prędkość: webGL> płótno
  • możliwości: webGL> canvas
  • koszt: webGL jest znacznie droższy
  • platforma: bardzo podobna

Mam nadzieję że to pomoże.

PS Otwarte do dyskusji.


@Abstract, gdzie są dobre tutoriale do web GL i ile godzin to zajmie?
Pacerier

1
@Pacerier po prostu wygoogluj to, pierwsze kilka trafień prawdopodobnie wystarczy. Jednak osiągnięcie dobra w webgl i ogólnie programowaniu graficznym zajmie tygodnie i miesiące, a lata, zanim będzie naprawdę dobra. Nie chodzi o jakąś przypadkową „bibliotekę”, do której trzeba się nauczyć API i to wszystko.
Abstract Algorithm

@AbstractAlgorithm, mam na myśli to, że jeśli jesteś mistrzem w programowaniu kanwy, ile godzin zajmie przejście na Web GL?
Pacerier

@Pacerier, który zależy od dewelopera i, jak powiedział Streszczenie, umiejętności matematyczne zaangażowanego programisty. Naprawdę nie można dokonać kwantyfikacji.
scrappedcola

32

Największą zaletą jest programowalność potoku i wydajność. Na przykład, powiedzmy, że rysujesz 2 pola jedno nad drugim i jedno jest ukryte, niektóre implementacje GL mają możliwość odrzucenia ukrytego pudełka.

Jeśli chodzi o porównania, ponieważ nie ma tutaj szybkiego sposobu na utworzenie tabeli, właśnie przesłałem zdjęcie tabeli porównawczej poniżej. Dodano Three.js tylko dla kompletności.

Stół


Re: „Niektóre implementacje GL mają możliwość odrzucenia ukrytego pola”, ale czy nie mógłbyś wykryć tej nadpisanej części w JS i tym samym nie przerysować tego, co nie jest potrzebne?
Pacerier

16

Mówiąc z doświadczenia w moich własnych aplikacjach , shadery grafiki były jedynym powodem, dla którego potrzebowałem wsparcia dla WebGL. Łatwość użycia nie ma dla mnie znaczenia, ponieważ oba frameworki można wyodrębnić za pomocą three.js. Zakładając, że nie potrzebuję shaderów, zezwalam na użycie obu frameworków, aby zmaksymalizować obsługę przeglądarki / komputera.


16

Jakie możliwości 2D oferuje WebGL, czego nie oferuje kanwa 2D? Największym IMHO są programowalne fragmenty shaderów na sprzęcie graficznym. Na przykład w WebGL można zaimplementować grę Conway's Game of Life w module cieniującym na sprzęcie 3D:

http://glslsandbox.com/e#207.3

Ten rodzaj wyświetlacza 2D działałby tylko na CPU, a nie na GPU, z płótnem 2D. Wszystkie obliczenia zostałyby zaimplementowane w JavaScript i nie byłyby tak równoległe jak GPU, nawet przy pomocy pracowników sieci. To tylko jeden przykład, oczywiście, wszystkie rodzaje interesujących efektów 2D można zaimplementować za pomocą shaderów.


2
Zatem w porównaniu z płótnem, czy WebGL jest mniej lub bardziej obciążające dla systemu operacyjnego?
Pacerier

Jestem ciekawy, czy i tak wszystkie płótna kończą się tworzeniem webgl; jeśli używa wstępnie skompilowanego wspólnego przypadku użycia webgl, co byłoby bardziej wydajne niż bezpośredni webgl; lub jeśli w żaden sposób nie łączy się z opengl, chyba że używasz webgl.
Dmitry

1
@Dmitry świetne pytanie, a różne przeglądarki mogą inaczej podejść do tego problemu. Ale bez względu na to, jak przyspieszają one API Canvas 2D, samo API Canvas 2D nie oferuje programowalnych shaderów ani buforów tablicy wierzchołków. Jest to „rozmowny” interfejs API (jedno wywołanie JavaScript-to-Native na każdy narysowany element), podczas gdy interfejs API WebGL umożliwia masowe ładowanie danych i przetwarzanie niestandardowe oparte na GPU.
emackey

14

Cóż, wydajność byłaby jednym z największych powodów, ponieważ podczas kodowania gry musi być szybka. Ale jest kilka innych powodów, dla których warto wybrać WebGL zamiast kanwy. Oferuje możliwość kodowania shaderów, oświetlenia i powiększania, co jest ważne, jeśli tworzysz komercyjną grę. Po mniej więcej 50 sprite'ach płótno zaczyna się opóźniać.


Szczególnie na urządzeniu takim jak tablet z Androidem, w którym procesor jest szybko przeciążany w JavaScript, głównym powodem korzystania z WebGL jest przeniesienie obciążenia renderującego na GPU.
Curtis

1
@ Xk0n, Re „fansuje możliwość kodowania shaderów, oświetlenia i powiększania”, ale czy w takim razie nie zależy to od GPU?
Pacerier

Nadal możesz powiększać za pomocą setTransform w kontekście płótna 2D. Miałem jednak trudności z krwawieniem tekstur na płótnie 2D podczas skalowania z arkuszy sprite, dlatego przechodzę na WebGL. Widziałem samouczek, który powstrzymuje próbkowanie najbliższego sąsiada przed wyjściem poza prostokąt źródłowy, co powinno rozwiązać mój problem z krwawieniem.
Frank

7

Nie ma nic, czego nie można zrobić z Canvas, czego nie można zrobić z webGL: płótno pozwala zmiażdżyć bajty za pomocą get / putImageData i możesz rysować linie, okręgi, ... programowo za pomocą webGL.
Ale jeśli chcesz zrobić trochę rysunków, a także niektóre efekty przy 60 fps, różnica w wydajności jest tak duża, że ​​nie będzie to możliwe w przypadku płótna, gdy będzie działał dobrze w webGL. Wydajność to podstawowa funkcja.

Jednak programowanie webGL jest dość skomplikowane: sprawdź, czy płótno jest dla Ciebie wystarczająco dobre lub poszukaj biblioteki, która złagodzi ból ...
Inna wada: nie działa w IE (ale co działa?) I na niektórych telefonach komórkowych.
Zobacz tutaj, aby sprawdzić zgodność: http://caniuse.com/webgl


7

Ponieważ szczególnie potrzebujesz klasycznych rzeczy 2d, które nie działają dobrze na płótnie:

  • kolor zmienia się (jak mruganie duszkiem)
  • powtarzanie wypełnień bitmapą
  • układanie map pod rotacją (pod płótnem niektóre implementacje utworzą szwy)
  • głębokie warstwowanie (bardzo zależne od implementacji)
  • mieszanie multiplikatywne lub addytywne

... ale oczywiście masz dostęp do pikseli, więc możesz zrobić naprawdę wszystko, łącznie z powyższym, ręcznie. Ale to może być naprawdę, bardzo powolne. Teoretycznie możesz emscripten Mesa openGl renderować na płótnie.

Innym ważnym powodem korzystania z webGL jest to, że wynik jest bardzo łatwy do przeniesienia w inne miejsce. Co również sprawia, że ​​umiejętność jest bardziej wartościowa.

Powody, dla których warto korzystać z płótna są takie, że jest ono nadal lepiej obsługiwane, a jeśli nauczysz się robić rzeczy piksel po pikselu, jest to również bardzo cenna lekcja.


Przy okazji czy WebGL jest wielowątkowy? Czy możesz mieć dwa wątki rysujące jednocześnie dwie części ekranu?
Pacerier

Myślę, że odpowiedź brzmi „tak i nie”, ponieważ przeglądarki internetowe są z natury jednowątkowe, więc kopiowanie danych, które mają być renderowane do GPU, nie jest wielowątkowe. Ale używasz masowej równoległości karty graficznej, gdy shadery zaczną renderować, co w zasadzie rysuje na wielu częściach ekranu jednocześnie. Proszę, popraw mnie, jeśli się mylę, ktoś.
Kent Weigel

2

Ponieważ WebGL jest szczególnie nową technologią, a kanwa HTML5 jest bardziej ugruntowana, to, czego chcesz używać, zależy od użytkowników. Jeśli myślisz, że Twoi użytkownicy będą korzystać z urządzeń mobilnych, sugerowałbym płótno HTML5, ale jeśli chcesz lepszego renderowania 2D, użyłbym WebGL. Możesz więc zrobić, jeśli renderowanie odbywa się na urządzeniach mobilnych z HTML5, a jeśli są na platformie obsługującej WebGL.

Na przykład:

 if (window.WebGLRenderingContext) {
     webGLcanvasApp()
         } else if( /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) ) {
     html5CanvasAppFMobile()
    } else {
    html5CanvasApp()
    }

Źródła:
właściwy sposób wykrywania obsługi WebGL?
Jaki jest najlepszy sposób na wykrycie urządzenia mobilnego w jQuery?


2

WebGL jest bezużyteczne bez GPU.
Ta zależność sprzętowa nie stanowi dużego problemu, ponieważ większość systemów ma procesory graficzne, ale jeśli architektury GPU lub procesora kiedykolwiek ewoluują, zachowanie zawartości webgl przez emulację może być trudne. Uruchamianie go na starych (zwirtualizowanych) komputerach jest problematyczne.

Ale „Canvas vs WebGL” nie musi być wyborem binarnym. Właściwie wolę używać webgl do efektów, ale resztę robię na płótnie. Kiedy uruchamiam go na VM, nadal działa ładnie i szybko, tylko bez efektów.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.