Сами узлы проще делать на html, а связи рисовать на svg. Производительней конечно на canvas, но то что на html или svg идет из коробки, на canvas придется делать самому. Как и в любом другом случаи, подводный камень это сам разработчик. Что для одного просто, то для другого несколько месяцев.
vasIvas: Спасибо. Я Вот тоже с коллегой сейчас обсуждал этот вопрос. В итоге от SVG мы отказались полностью по причине его производительности (P.S. зато он прост в реализации черт-возьми).
Далее остается HTML и CANVAS:
canavas - быстрый, но сложнее реализовывать.
html - "практически" тоже не уступает в производительности от canvas (Замеры производительности), но тут единственный минус, что связи требуется прорисовывать на canvas или svg, тем самым получая мини зоопарчик в котором теряется производительность (svg) или сложность реализации (canvas).
sim3x: Пожалуйста, обратите внимание на мой пост выше, то увидите ссылку с тестами + замерами производительности. P.S. так же по ссылке можно запустить самостоятельно тесты с разными параметрами.
d-virt:
Вы делаете игрушку в которой будет масса кружочков?
Нет?
Почему вы ориентируетесь на фпс сцены с кружочками для проектирования UML?
Для проектирования UML важен фпс?
sim3x: К сожалению, не известно. Т.к. не возможно предугадать объем информации, которая будет отрисована на полотне.
Так же не известно на сколько быстро будет работать zoom полотна в соотношение объемов и выбранной той или иной технологией.
Я прекрасно понимаю, что у меня НЕТ анимации (где эффективно использовать в canvas), но так же понимаю, если много SVG элементов, то браузер начинает подлагивать.
А так да, Вы правы, FPS не требуется для реализации UML, т.к. там нет анимации (за исключением dragAndDrop объектов).
sim3x: Большое спасибо за ответ. Само собой требуется реализация тестового полигона. Но если вернуться обратно к теме вопроса, то его суть о подводных камнях, которые могут не всплывут на тестовом полигоне.
На тестовом полигоне у вас не всплывут
- отсутствие библиотек
- осутствие квалификации для написания своего фреймворка
- отсутствие понимания, что требуется клиентам
- интеграции с внешними ресурсами
sim3x: Спасибо, но вот другой вопрос. Есть:
gojs на canvas и d3js на svg
И почему одни взяли canvas а другие svg при условии, что практически они решают одни и те же задачи ?
sim3x: продукт может не взлететь из-за того, что производительность плохая. Для средств рисования это один из критических параметров. Наглядный пример - попытка заменить планшетом бумагу. Единственная более-менее удачная попытка это самый последний iPad Pro.
d-virt при разработке подобного продукта следует проанализировать предметную область, посмотреть на другие продукты. Клиенты, которые могут принести вашему бизнесу деньги будут иметь сложность на уровне выше 1000 элементов в модели.
Лично я бы рекомендовал смотреть в сторону SVG поскольку это изначально векторный формат, поэтому вещи вроде масштабирования или копирования будут намного проще.
Philipp: Спасибо. К сожалению, введу своей производительностью, как-то боимся брать SVG и сейчас смотрим в сторону canvas. Начал писать прототип для canvas и столкнулся с такими проблемами, как:
1) При изменения окна разрешения браузера, придется перерисовать весь холст.
2) Получить ширину (точную, а не приблизительную!) и высоту текста при помощи canvas на текущий момент нельзя (знаю можно костылям через виртуальный дум елемент, т.е. css, пугает, что это костыль).
Это пока единственные сложности, которые у меня возникли при реализации прототипа на canvas. Знаю, что в SVG таких проблем нет.
И отойду чуть-чуть от темы, по поводу iPad Pro, на сколько я знаю, в данный момент лидером в этом вопросе - "заменить планшетом бумагу", выступает Wacom и как показала практика и время на нём реально рисуют крутые вещи.
Производительность не должна быть приоритетной задачей, пока пользователи не заинтересовались
Если пользователи пользуются, даже учитывая тормоза, значит продукт стоящий вложений времени в тч и на оптимихацию скорости
Первый iPhone тоже был ужасным продуктом, но в нем была решена проблема отзывчивости интерфейса - т.е. производительности. В то время уже были наработки сенсорных телефонов, но все имели тормоза.
Если продукт будет неудобен в использовании при наличии удобных аналогов - им никто не будет пользоваться.
Если интересно, то gojs мне показался неудобным. При перетаскивания и масштабировании появляется какое-то мыло на тексте. В тоже время d3 работает просто чудесно.
Безусловно, d3 достроенное решение, но, к сожалению, пока нет понимая, как его связывать с canvas (если есть какой-нибудь мануал на эту тему, подкиньте, пожалуйста).
Что касается gojs, то мне не понравилось то, что выделенный объект при перетаскивание путем наложение на другого объекта, данный объект рисуется на заднем плане, а не на переднем (P.S. по край мере так в примерах).
d-virt: d3 работает с svg. Это по сути и есть генератор SVG изображений. У меня коллега довольно сложные графики на нем строил, плюс добавлял к ним разную анимацию. Выглядело классно и работало быстро даже на телефоне.
