Лучшая стратегия для хранения почерка

Question

Я пишу мобильное приложение (Android), которое позволит пользователю «писать» на холст, используя устройство с одним касанием и точностью до 1 пикселя. Приложение будет работать на планшетном ПК размером примерно 8 1/2 "x 11". Моя стратегия заключается в том, чтобы хранить «текст» в виде векторных данных, так как каждый штрих устройства ввода по существу будет вектором, состоящим из начальной и конечной точек, а также некоторого количества промежуточных точек, которые помогают определить форму вектор (генерируется сенсорным экраном / ОС при сенсорном движении). Это должно позволить мне отслеживать порядок, в котором были нанесены штрихи (для поддержки отмены и т. Д.), И быть достаточно гибким, чтобы можно было изменять размер текста и т. Д., Как и любая другая векторная графика.

Тем не менее, выполняя некоторые очень грубые расчеты конверта, с высокоточным устройством ввода и большим экраном, позволяющим эмулировать один за одним стандартный бумажный блокнот, то есть у вас будет ~ 1700 штрихов в полная страница текста. В худшем случае можно предположить, что каждый штрих может состоять из ~ 20-30 отдельных точек (точка для каждого пикселя или около того штриха), что означает ~ 50 000 точек данных на странице ... Слишком большой для SQLite / Android для обработки с любым ожиданием надежности при перезагрузке страницы и воссоздании векторных штрихов (я должен представить, что получение 50 000+ результатов из базы данных SQLite превысит ограничение CursorWindow в 1 МБ )

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

Любые предложения о том, как решить эту проблему более эффективным способом?

Спасибо!

Пол

Answer 1

Решение, которое я использую сейчас, хотя я был бы открыт для любых дальнейших предложений!

1. Создание холста, который может как преобразовывать пути SVG в пути Android, так и перехватывать события движения, преобразовывая их в пути Android, а также сохранять их как пути SVG.
2. Отображение путей Android на экран в onDraw ()
3. Запишите пути SVG в файл .svg

Пол

Answer 2

Есть ли причина использования векторных данных в первую очередь?Не зная ваших других требований, мне кажется, что вам просто нужно хранить данные в растре / растровом изображении и сжимать их с помощью обычных методов сжатия, таких как PNG / zip / djvu (или, если производительность страдает, простых вещей, таких как кодирование по длине прогона)./ RLE).

РЕДАКТИРОВАТЬ: извините, я не прочитал вопрос ясно.Однако, если вам нужны только такие вещи, как «отменить» и «изменить размер», вы можете сделать снимок растрового изображения для каждого мазка (конечно, вам нужно только сделать снимок областей, которые меняются).

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

Кроме того, я не знаком с пределом курсора Android, но запросы SQL могутвсегда переписывать, чтобы разделить результат на части (через LIMIT ... OFFSET).