Проблемы с Android Path Path / решения - PullRequest
0 голосов
/ 13 июля 2011

У меня есть приложение для рисования в Android, которое позволяет пользователю рисовать пальцем, а затем сохраняет полученные формы как Android Path s. Чтобы позволить пользователю удалять отдельные Path нарисованные ими, я реализовал это решение , которое использует ограничивающий Rect для каждого Path, а затем использует внутренний многомерный двоичный массив для представляют пиксели внутри ограничивающего Rect. Затем я заполняю массив, беря контрольные точки Path и отслеживая его, используя математическое уравнение для квадратичной кривой Безье, устанавливая каждый элемент в массиве, который будет иметь пиксель под ним, равным 1.

Используя описанную выше настройку, в режиме стирания я сначала проверяю столкновение между пальцем пользователя и ограничивающим Rect, а если оно сталкивается, то я проверяю, установлено ли на пиксель, которого касается пользователь 1 в массиве.

Теперь, когда пользователь загружает заметку, я загружаю все фигуры в ArrayList объектов «обводки», чтобы затем их можно было легко отображать и проходить по ним, проверяя наличие столкновений в режиме стирания. Я также храню Rect и двоичный массив со штрихами в пользовательском объекте. Все работает, как и ожидалось, но объем памяти, в которой хранятся все эти данные, в частности двоичный массив для каждого пути, ограничивающий Rect, становится дорогим, и когда у пользователя большое количество ударов, я получаю java.lang.OutOfMemoryError на части моего кода, который создает массив для каждого штриха.

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

Спасибо

Пол

1 Ответ

0 голосов
/ 13 июля 2011

Каково фактическое представление «двоичного массива»? Я думаю, что если вы настроите представление так, чтобы оно отражало фактические данные, которые вам нужно сохранить (например, RLE кодирует биты: при этом y, начиная с этого x и для z пикселей), вы сможете хранить то, что вам нужно, без чрезмерного размера.

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

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

...