Чи є причина використовувати WebGL замість 2D Canvas для 2D ігор / додатків?


112

Чи є якась причина, крім продуктивності, для використання WebGL замість 2D-Canvas для 2D ігор / додатків?

Іншими словами, які 2D-функції пропонуються WebGL, яких неможливо легко досягти за допомогою 2D-Canvas?


5
До речі: Хоча ви не можете використовувати API 2d та 3d контексту на одному полотні, ви все одно можете комбінувати їх, використовуючи кілька полотен. WebGL може використовувати 2d полотна в якості текстур, а 2d полотна можуть використовувати полотна WebGL як джерела для drawImage.
Філіп

Відповіді:


83

Дивлячись на це питання з іншого боку:
як розробник вибирає одну технологію над іншою?

  • краще інтегрується у свою вже побудовану систему
  • простіший у використанні
  • швидше
  • має більше можливостей або краще відповідає їх потребам
  • вартість
  • більше незалежно від платформи

Тому я обговорюю відмінності між canvas та webGL API щодо цих якостей.


І канва, і webGL - це API API. Вони майже однакові щодо інтеграції (прив'язки). Вони підтримуються низкою бібліотек, які можуть пришвидшити ваше кодування. Різні бібліотеки дають вам різні способи впорядкування вашого коду, тому вибір бібліотеки диктує, як структуровані API для малювання, але це все одно майже те саме (як решта коду пов'язується разом із ним). Якщо ви використовуєте бібліотеку, простота написання коду залежить від самої бібліотеки.

Якщо ви пишете код з нуля, API полотна набагато простіше вивчити та зрозуміти. Це вимагає мінімальних знань з математики, а розвиток швидкий і простий.

Робота з API WebGL вимагає міцних математичних навичок та повного розуміння конвеєра рендерінгу. Людей з цими навичками знайти важче, виробництво повільніше (через розмір та складність такої бази коду), а тому коштує дорожче.

WebGL швидший і має більше можливостей. У цьому немає сумнівів. Це власний 3D API, який надає вам повний доступ до конвеєра рендерингу, код і ефекти виконуються швидше і є більш "підхідними". Для webGL насправді немає меж.

І полотно, і webGL - це смакота html5. Зазвичай пристрої, які підтримують одне, підтримуватимуть, а інше.

Отже, підводячи підсумки:

  • злиття коду API малювання та решта (інтеграція): аналогічно
  • простота використання:
    • (з бібліотекою) canvas = webGL
    • (з нуля) webGL << полотно
  • швидкість: webGL> полотно
  • можливості: webGL> полотно
  • вартість: webGL набагато дорожче
  • платформа: дуже схожа

Сподіваюся, це допомагає.

PS Відкрито для обговорення.


@ Абстрактно, Де є хороші підручники для веб-GL та скільки годин це займе?
Pacerier

1
@Pacerier просто google it, перші кілька хітів, ймовірно, досить хороші. Тим не менш, знадобляться тижні і місяці, щоб зайнятись веб-програмою і графічним програмуванням взагалі, а роки справді будуть хорошими. Це не просто якась випадкова "бібліотека", для якої потрібно вивчити API, і все.
Абстрактний алгоритм

@Ab абстрактAlgorithm, я маю на увазі, якщо ви є майстром з програмування полотна, скільки годин пройде перехід до веб-GL?
Pacerier

@Pacerier, що залежить від розробника, і, як абстрактно вже говорив, математичні навички залученого розробника. Насправді немає кількісного визначення, яке можна зробити.
scrappedcola

32

Найбільша перевага - це програмованість трубопроводу та продуктивність. Наприклад, скажімо, що ви малюєте 2 вікна один над одним, а одне приховано, деякі реалізації GL мають можливість відмовитись від прихованого поля.

Що стосується порівнянь, оскільки тут немає швидкого способу створення таблиці, я просто завантажив зображення таблиці порівняння нижче. Додано Three.js лише для повноти.

Таблиця


Знову "у деяких реалізаціях GL є можливість відмовитись від прихованої скриньки", але чи не вдалося ви виявити цю перекриту частину в JS і, отже, не перемалювати те, що не потрібно?
Pacerier

16

З огляду на досвід власних додатків , графічні шейдери були єдиною причиною, коли мені потрібна підтримка WebGL. Простота використання для мене мало стосується, оскільки обидві рамки можна абстрагуватись від three.js. Припускаючи, що мені не потрібні шейдери, я дозволяю використовувати будь-який фреймворк для максимальної підтримки браузера / машини.


16

Які можливості 2D пропонує WebGL, що 2D-полотно не має? Найбільшим IMHO є програмовані шейдери для фрагментів графічного обладнання. Наприклад, у WebGL можна реалізувати «Гра життя» Conway в шейдері на вашому 3D-обладнання:

http://glslsandbox.com/e#207.3

Цей вид 2D-дисплея працюватиме лише на процесорі, а не на графічному процесорі, з 2D-полотном. Усі обчислення були б реалізовані в JavaScript, і не були б такими паралельними, як GPU, навіть за допомогою веб-працівників. Це лише один приклад, звичайно, всі види цікавих 2D-ефектів можна реалізувати за допомогою шейдерів.


2
Таким чином, проти полотна, чи WebGL більш-менш оподатковує ОС?
Pacerier

Мені цікаво, чи все-таки полотно закінчиться робити webgl; якщо він використовує попередньо складений загальноприйнятий регістр webgl, який був би більш ефективним, ніж прямий webgl; або якщо він жодним чином не взаємодіє з opengl, якщо ви не використовуєте webgl.
Дмитро

1
@Dmitry велике запитання, і різні браузери вільно застосовувати різні підходи до цієї проблеми. Але, як би вони не прискорювали API Canvas 2D, сам API Canvas 2D не пропонує програмованих шейдерів або буферів вершинного масиву. Це API "чат" (один виклик JavaScript на Native на один елемент), тоді як API WebGL дозволяє групове завантаження даних та користувальницьку обробку на основі GPU.
emackey

14

Що ж, продуктивність була б однією з найбільших причин, тому що коли ви кодуєте гру, вона повинна бути швидкою. Але є кілька інших причин, через які ви можете вибрати WebGL через полотно. Він пропонує можливість кодування шейдерів, освітлення та масштабування, що важливо, якщо ви робите комерційне додаток для ігор. Полотно також стає млявим після 50 спрайт або близько того.


Особливо на пристрої на зразок планшета Android, на якому процесор швидко перевантажується javascript, головна причина використання WebGL - перенесення завантаження візуалізації на GPU.
Кертіс

1
@ Xk0n, Re "надає можливість кодування шейдерів, освітлення та масштабування", але чи не це стає GPU-залежним?
Pacerier

Ви все ще можете збільшити масштаб за допомогою setTransform у контексті 2D-полотна. Однак у мене важко спостерігається кровоточивість текстури у двовимірному полотні при масштабуванні з аркушів спрайту, тому я звертаюся до WebGL. Я побачив підручник, який перешкоджає відбору проб найближчого сусіда виходити за межі вихідної прямої кишки, що повинно вирішити мою проблему з кровотечею.
Френк

7

З Canvas ви нічого не можете зробити, чого не можете зробити з webGL: полотно дозволяє розчавити байти за допомогою get / putImageData, і ви можете намалювати лінії, кола ... програмно за допомогою webGL.
Але якщо ви хочете зробити декілька малюнків, а також деякі ефекти при 60 кадрів в секунду, розрив у продуктивності настільки великий, що просто неможливо буде з полотном, коли він буде працювати нормально в webGL. Продуктивність є кореневою особливістю.

Однак webGL є досить складним у програмі: подивіться, чи є полотно достатньо для вас, або шукайте бібліотеку, яка полегшить біль ...
Інший недолік: він не працює на IE (але що робить?) Та на деяких мобільних телефонах.
Дивіться тут про сумісність: http://caniuse.com/webgl


7

Оскільки ви конкретно хочете отримати класичні 2d речі, які не добре працюють із полотном:

  • кольорові перетворення (як блимання спрайта)
  • повторення растрових заповнень
  • плитка карти під обертанням (під полотном деякі реалізації створюватимуть шви)
  • глибокий шар (залежить від реалізації)
  • мультипликативне або аддитивне змішування

... але, звичайно, ви маєте доступ до пікселів, тому ви можете робити дійсно все, в тому числі вище, вручну. Але це може бути справді, дуже повільно. Ви можете виписати Mesa openGl, щоб теоретично відобразити полотно.

Ще однією важливою причиною використання webGL було б те, що результат дуже легко переноситься в інше місце. Що також робить вміння більш цінним.

Причини використання полотна полягають у тому, що він все-таки краще підтримується, і якщо ви навчитесь робити речі піксель за пікселем, це теж дуже цінний урок.


Btw Чи WebGL багатопотокова? Чи можете у вас дві нитки одночасно малювати дві частини екрана?
Pacerier

Я думаю, що відповідь - «так і ні», оскільки веб-браузери за своєю суттю є однопотоковими, тому копіювання даних, що надаються в GPU, не є багатопотоковою. Але ви використовуєте масштабну паралелізацію відеокарти, як тільки шейдери почнуть відображати, що по суті є малюнком на декілька частин екрана одночасно. Будь-ласка, виправте мене, якщо я не прав, будь-хто.
Кент Вейгель

2

Оскільки WebGL - це особливо нова технологія, і на полотні HTML5 більш встановленим є те, що ви хочете використовувати, залежить від ваших користувачів. Якщо ви думаєте, що ваші користувачі використовуватимуть мобільні пристрої, тоді я б запропонував канву HTML5, але якщо ви хочете кращого 2D-рендерінгу, я б використовував WebGL. Тож, що ви можете зробити, це якщо мобільне візуалізація використовується разом із HTML5, якщо вони є на платформі, яка підтримує WebGL.

Наприклад:

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

Джерела:
Правильний спосіб виявити підтримку WebGL?
Який найкращий спосіб виявити мобільний пристрій у jQuery?


1

WebGL непридатний без GPU.
Ця апаратна залежність не є великою проблемою, оскільки більшість систем мають графічні процесори, але якщо архітектури GPU чи CPU колись розвиваються, збереження вмісту webgl шляхом емуляції може бути складним завданням. Запустити його на старих (віртуалізованих) комп’ютерах проблематично.

Але "Canvas vs WebGL" не повинен бути бінарним вибором. Я фактично вважаю за краще використовувати webgl для ефектів, а решту виконую на полотні. Коли я запускаю його в VM, він все ще працює красиво і швидко, просто без ефектів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.