Параллельный чертеж с paper.js

Question

У меня есть приложение, которое имеет дело с виджетами на основе paper.js. Несколько пользователей могут рисовать одновременно, а изменения передаются друг другу в режиме реального времени. Проблема в том, что мне нужно сохранить изменения и отобразить образы, пока документ загружен.

Естественным решением является сохранение команд, отправленных клиентами в БД. Но обратные изображения могут состоять из тысяч команд, и я могу иметь десятки изображений. Поэтому, когда я открываю документ, получая список команд с сервера, рисование может занять слишком много времени.

Есть ли лучший способ хранения изображений и взаимодействия между клиентами?

Обратите внимание, что у меня есть функция масштабирования, поэтому сохранение растра не является вариантом.

UPDATE: Если я храню изображение (например, в BLOB), неясно, как применять изменения, внесенные в реальном времени. Передача изображения каждый раз не является решением, которое я хочу.

Answer 1

Если вы собираетесь сохранить рисунок как изображение, у вас есть несколько возможных решений.

1. Сохранить пункт где-то в папке и сохранить путь к каталогу + имя файла в базе данных
2. Сохранение изображений в базе данных как blob. Тем не менее, Blobs действительно интенсивно работают с базой данных.

Есть несколько интересных статей о блобе. Как this one от microsoft.

Как и ожидалось из общей мудрости, объекты размером менее 256 КБ лучше всего хранятся в базе данных, а объекты размером более 1 М лучше всего хранятся в файловой системе.

Таким образом, это будет лучшим решением для сохранения изображения в каталоге.

Также можно экспортировать файл с рисунком svg. (info) Я не знаю, поможет ли это вам, но это мой личный опыт. И я согласен с вами в том, что хранение тысяч команд в базе данных не лучшее решение. Поэтому вы можете захотеть взглянуть на сохранение изображений где-нибудь, но тогда вы потеряете возможность редактировать изображение, если у вас это реализовано.

Update:

Если вы не хотите, чтобы сэкономить blob лучшим решением было бы «вынести» изображение на каждый раз редактировать производится. Таким образом, вы можете выполнять все команды, когда кто-то открывает чертеж. Применяйте только последние команды при запуске редактирования.

Существует несколько вариантов достижения этого. Например Jimmy Chandra сказал, firebase было бы хорошим решением. Они также предоставляют tutorial с почти всем, что вы хотите достичь. (рисование изображения с использованием x и y координат в реальном времени) Возможно, вам стоит взглянуть на это.

Немного больше информации о Firebase.

Firebase мощный API для хранения и синхронизации данных в режиме реального времени

Это именно то, что вы хотите достичь, я верю. Вы можете попробовать полный учебник here.

Другой вариант, который вы можете принять во внимание, - nodejs. Я видел людей, использующих nodejs для чат-систем для отправки данных всем другим пользователям. Если вы можете отправлять данные, я уверен, что вы можете сделать с ним изображение.

В конце концов, вам решать, какую технологию вы хотите использовать. Поэтому я думаю, что вам придется исследовать несколько решений, как я предложил, и задать другой вопрос, если у вас возникнут проблемы с интеграцией этой технологии.

Answer 2

Сохраняются ли данные на стороне клиента в качестве вторичного хранилища?

С himl5-файлом api должна быть возможность сохранить копию всех команд сохранения, отправленных клиентами в БД. Таким образом, в следующий раз, когда он откроет документ, приложение будет отображать чертеж из вторичного хранилища, одновременно запрашивая на сервере последние обновления, эти обновления будут добавляться после того, как вторичное хранилище закончит рендеринг.

С помощью websockets вы можете сохранять команды и транслировать изменения другим клиентам и, следовательно, обновлять их чертеж с изменениями в реальном времени.

Answer 3

2 года назад Я разработал нечто подобное (в команде, закрытый код).

Первое, что нужно отметить, это то, что что-то подобное уже разрешено документами google. Мы читаем каждое сообщение в блоге и статью о том, как они это сделали, и применили это к многопользовательскому SVG, как простой редактор. Итак, вот что я помню:

Поломка простых команд - это правильный путь. Как вы писали, с ними вы можете очень быстро воссоздать свои изображения. Вы даже можете точно ответить на то, что изображение просматривало каждую запрограммированную метку времени.

Примера команды могут быть

- change color 
- change color again 
- draw a line from .. to .. 
- draw a line from .. to .. 
- draw a line from .. to .. 
- draw a line from .. to .. 
- smooth that line 
- change color 
- change Stroke 
- delete those lines and draw them again ;-) 

Перейти к примеру Goolge Документов, они сохранять и транслировать каждое изменение символов (и более).

Да, это очень понятный и проверяемый подход, но для запроса требуется другой логический уровень. Необходимо добавить процедуру, упрощающую эти команды для сжатой версии (см. Ниже)

В тот момент, когда пользователь запрашивает изображение, ваша система ищет последнее сжатое изображение и добавляет отдельные команды, не включенные в ваш компресс рутина.

Компресс рутина:

Сделайте видеозапись создания фиктивного образом (подобно тому, что вы ожидаете от вас пользователей) в вашем любимом векторном редакторе, вы заметите, что около 60% до 80% процентов команд бесполезны до конечного результата.

Целевая подпрограмма компресс может иметь следующие три шага:

1. Большую часть времени вы будете видеть себя в точках записи репозиции, ручки или перемещение объектов, изменить цвет снова и снова установка и погубило другие параметры, такие как толщина поршня. Даже удаление повторного набора элементов. Подпрограмма должна оптимизировать эти команды для непосредственного вывода конечного результата. Я уверен, это уменьшит ваш список команд до 10% -50% в зависимости от типа изображения, которое вы ищете.

2. компрессионные команды. Путь в приведенном выше примере рисуется в сегментах строк, он должен. Обычно вы не знаете на первом onMouseDown, что он закончится на пути с 100 сегментами и 200 ручками. Но все равно, как и другие пользователи, чтобы показать процесс создания. Добавьте команду в свою программу, которая может рисовать сложные вещи, такие как путь. Это не понадобится в процессе рисования пользователя. Эта команда может использоваться для более быстрого восстановления полных фигур. Путь с 100 точками и 200 ручками теперь можно сделать в одной команде. До этого у вас был список по меньшей мере 300 команд.

3. Команды переупорядочения. Два элемента пути, нарисованные двумя пользователями одновременно, нелегко сжать. Простым решением является сортировка команд по элементу. Для создания каждой фигуры процесс может занять 3 минуты. Для анимации потребуется реальный командный порядок, чтобы каждый из них разрабатывался в одно и то же время, но конечный результат не волнует. Каждая форма может быть намного легче сжата, если она упорядочена по элементу.

извините за длинный пост, надеюсь, что это помогает

Answer 4

Я дам более широкий ответ с архитектурными рекомендациями так извинениями заранее перфекционисты.

Я хотел бы использовать Nginx и nodejs с WebSockets как мой уровень приложения, и использовать paperjs на моей стороне сервера с помощью НОГОhttps://www.npmjs.com/package/paper

Для моего уровня настойчивости я бы не только использовать БД кластер (mysql/mongodb и т. д.), но также использовать redis как кеш команд.

Всякий раз, когда команды выполняются на холсте я упорно его в Redis и трансляции для всех клиентов через socket.io, и, наконец, прекратить/сохранения/выхода и т.д. события, вызванные любым пользователем, я бы упорствовать его как изображение в моем db, или fs с ссылкой на путь в моем db.

Надеюсь, это поможет.