из статьи-Это трудности в синхронизации и, главное, невозможность реализации более сложных фигур.
Но, как раз трудностей и нет-да и в вариате с визуальным рисованием фигур любой сложности всё будет проще(хоть каляку маляку-определить только внешние точки для эрии-не сложно.заодно можно и каляки маляки не замкнутые делать). Если фигура не закрашена и клик внутри её, то жизнь с алгоритмом с хабра значительно усложнится.Да и насколько понимаю при одинаковом цвете с наложением будет не так всё просто(это о преимуществе массива над объектом в этом случае в массиве 3х мерном можно индексы по типу z ставить,хотя что мешает с объектом тоже их ставить.. ).
хотя по поводу быстрее-наверное быстрее отработает взаимодействие со множеством эриий чем его код со множеством фигур.хотя,на объектах ресурсов меньше сожрёт,но сложность фигур ограничена и вычислений поболее со сложной фигурой(например-не многоугольник из прямых,а фигура комбинация прямых и дуг-нарисованная в визуальном режиме.либо фигура в форме бублика-уже никак без наворотов кода).И в итоге для сложных он так разрастётся,чего не произойдёт с массивом и эриями. да и с эриями и массивом можно готовые изображения вставлять(закидывать в канву тоже фото) и с лёгкостью манипулировать им
у всего плюсы и минусы есть.

dmitriymar, на самом деле, есть заблуждение, что реализованное на нативном dom будет быстрее, чем на js. Так вот. Не забывайте, что dom - ужасно медлителен по своей сути и тащит за собой кучу абстракций. это не всегда так

Автору темы - дока по LC лежит на ГитХабе: https://github.com/theshock/libcanva...master/Docs/Ru

Shock,
сделал реализацию подобного через canvas+svg. на скорость нареканий нет-меня устраивает. а dom-реализация событий у вас на канве его всё равно используtт. дак и смысл используя его говорить что он не используется?
а как это? всегда считал что результат добивается взаимодействием(грубо) js(vbs..) и Dom ,но не по отдельности