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?
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?
Odpowiedzi:
Patrząc na to pytanie z innej strony: w
jaki sposób programista wybiera jedną technologię, a nie inną?
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ć:
Mam nadzieję że to pomoże.
PS Otwarte do dyskusji.
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.
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.
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.
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ć.
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
Ponieważ szczególnie potrzebujesz klasycznych rzeczy 2d, które nie działają dobrze na płótnie:
... 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.
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?
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.