Comments 15
А как же код? А репозиторий на гитхаб?
+3
поскольку в итоге нашел заказчика на коммерческий продукт, то полноценных исходников, к сожалению, не будет
Одно из условий заказчика, не выкладывать исходники в открытый доступ. В принципе, мне было бы достаточно идей и описания ошибок, которые не стоит повторять.
0
Возможно, пригодится для оптимизации контуров: github.com/mourner/simplify-js
+1
Зачем планируете переводить работу с объектами на SVG?
0
Потому что как показала практика, работа с объектами в CANVAS дико геморройная.
Пример: чтобы определить, что мы навели мышку на контур сложной формы, нарисованный в canvas, необходим вагон плясок с бубном. Либо мы должны хранить данные в MAP для картинки, которая лежит поверх canvas (но тогда проблемы с фиксацией наведения собственно на canvas и оформление различных подсветок), либо сойти с ума и писать на JS проверку на попадание точки в контур самостоятельно. В случае же с SVG, вешаем на готовый контур-объект любые события, хоть подсветку, хоть переход по ссылке, описываем оформление в CSS и все, готово. Кроме того, если объектов будет много — их обработчик на JS тачнет ощутимо томрозить, а в случае с SVG, мы работаем только с текущим объектом и не паримся.
Но в итоге ситуация выглятит так: вся работа с объектами, например, выбор, подсветка — проходит через SVG, редактирование же происходит в canvas, поскольку там реально проще получить кусок картинки и/или перевести кусок в массив для дальнейшей работы.
Пример: чтобы определить, что мы навели мышку на контур сложной формы, нарисованный в canvas, необходим вагон плясок с бубном. Либо мы должны хранить данные в MAP для картинки, которая лежит поверх canvas (но тогда проблемы с фиксацией наведения собственно на canvas и оформление различных подсветок), либо сойти с ума и писать на JS проверку на попадание точки в контур самостоятельно. В случае же с SVG, вешаем на готовый контур-объект любые события, хоть подсветку, хоть переход по ссылке, описываем оформление в CSS и все, готово. Кроме того, если объектов будет много — их обработчик на JS тачнет ощутимо томрозить, а в случае с SVG, мы работаем только с текущим объектом и не паримся.
Но в итоге ситуация выглятит так: вся работа с объектами, например, выбор, подсветка — проходит через SVG, редактирование же происходит в canvas, поскольку там реально проще получить кусок картинки и/или перевести кусок в массив для дальнейшей работы.
0
Да, я видел ваши статьи и вот цитата из одной из них:
Понятно, что вы не 3 года без отрыва работали над редактором, но у меня не было ни времени, ни особого желания биться головой о canvas, когда под руками лежит SVG, где все гораздо проще.
«Почти всё готово, осталось немножко всякой фигни по мелочам». Прошло три года. Сейчас в голове — «Вот теперь точно почти всё готово!».
Понятно, что вы не 3 года без отрыва работали над редактором, но у меня не было ни времени, ни особого желания биться головой о canvas, когда под руками лежит SVG, где все гораздо проще.
0
Конечно, если писать велосипед на каждый маленький алгоритм, то работа с канвасом будет гемморойной. Почему было не взять один из готовых фреймворков, которые дают возможность работать с более продвинутыми примитивами? Например KineticJS. Такой редактор пишется за пару дней.
+1
Делал похожий редактор на основе проекта: github.com/summerstyle/summer, но без автоопределения контуров. Интересно было бы потыкать в демо вашего редактора. :)
+2
В этом редакторе мне понравился не только функционал, но и то, что его разработчик — девушка. А так — да, SVG редактор, все что нужно типовое — поддерживает, включая выгрузку в HTML. Я его, кстати, всерьез рассматривал как основу, но в итоге отказался, слишком тяжеловесный, мне нужно было что-то легче.
+1
Sign up to leave a comment.
Разработка векторного редактора на JavaScript (сложности и идеи)