Я ищу любые оптимизации, которые я могу сделать в программе редактирования графики - PullRequest
6 голосов
/ 14 февраля 2011

Привет, это мой первый раз, когда я задаю вопрос здесь, так что простите меня, если я что-то напутал> ~ <</p>

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

Я настроил его так, чтобы холст "бесконечно" расширялся во всех направлениях и состоял из 512x512 блоков пикселей, которыене становитесь активными, пока они не нарисованы, что должно быть действительно легко сделать, и я думал об использовании Direct3D для аппаратного ускорения, таким образом, 512 квадратных блоков.

Моя проблема возникает, когда яЕсли вы хотите использовать слои, я не совсем уверен, как я могу составлять слои быстро и без использования тонны памяти, поскольку моя цель - совместимые с DirectX9 видеокарты с 128 м памяти и системой с процессором мощностью около 3,2 ГГц и между2 и 8 концертов оперативной памяти.У меня было несколько разных подходов, которые я собирался использовать, и мне было интересно, какой из них, вероятно, будет лучшим, и если есть что-то, что я мог бы изучить, чтобы заставить его работать лучше.

Моя первая идея состояла в том, чтобы сделать gfxаппаратные средства выполняют как можно больше работы, поскольку все слои на всех блоках служат текстурами, и они будут обновляться путем блокировки измененной области, обновления их в процессоре и разблокировки их.Блоки, которые в настоящее время не изменяются, сведены в одну текстуру, а отдельные слои хранятся в системной памяти, что уменьшит объем используемой памяти gfx, но может значительно увеличить использование полосы пропускания между системной и памятью gfx.Я вижу, что постоянная блокировка и разблокировка также могут сильно замедлять работу системы.Другая возможная проблема заключается в том, что я слышал, как некоторые люди используют до 200 слоев, и я не могу придумать каких-либо хороших способов оптимизации, учитывая вышесказанное.

Моя другая идея состояла в том, чтобы составить текстуры полностью- в системной памяти запишите их в текстуру и скопируйте эту текстуру в память gfx для визуализации в каждом блоке.Похоже, это устраняет многие проблемы с другим методом, но в то же время я перенесу всю работу в ЦП, а не балансирую его.Это не имеет большого значения, пока он все еще работает быстро, хотя.Опять же, однако, есть проблема наличия нескольких сотен слоев.В этом случае, однако, я мог бы, вероятно, обновить только последние пиксели, которые на самом деле меняются, что, как я думаю, делают крупные именные программы, такие как Sai и Photoshop.

Я в основном ищу рекомендации, предложения, которые могли быулучшить вышеупомянутые, лучшие методы или ссылки на статьи, которые могут быть связаны с таким проектом.Пока я пишу это на C ++, у меня нет проблем с переводом с других языков.Спасибо за ваше время ~

1 Ответ

4 голосов
/ 14 февраля 2011

Структура данных Вам определенно следует использовать квадродерево (или другую иерархическую структуру данных) для хранения холста, и его узлы должны содержать много блоков меньшего размера, чем 512x512 пикселей.Может быть, не так мало, как 1x1 пикселей, потому что тогда иерархические издержки убьют вас - вы найдете хороший баланс при тестировании.

Рисование Пусть ваши пользователи используют только одно (самое высокое) разрешение.Представьте себе бесконечно большую равномерную сетку (двумерный массив).Поскольку вы знаете положение мыши и сумму, которую ваши пользователи прокручивали с начала координат, вы можете получить абсолютные координаты.Пройдите через квадродерево в эту область (в конечном итоге добавив новые узлы) и вставьте блоки (например, 32x32), когда пользователь рисует их в квадродереве.Я бы буферизовал то, что пользователь рисует в двумерном массиве (например, размером с разрешение экрана), и использовал отдельный поток, чтобы пройти / изменить дерево квадрантов и скопировать данные из буфера, чтобы обойти любые задержки.

Rendering Обходить дерево квадрантов, копировать все плитки в одну текстуру и отправлять ее в графический процессор?Нет!Видите ли, отправка поверх одной текстуры размером с разрешение экрана не является проблемой (с точки зрения пропускной способности).Но обходить квадродерево и собирать окончательное изображение (по крайней мере, если вы хотите много кадров в секунду).Ответ заключается в том, чтобы хранить квадродерево в системной памяти и передавать его из графического процессора.Означает: асинхронно другой поток выполняет обход и копирует данные, просматриваемые в данный момент, в графический процессор как можно быстрее.Если ваш пользователь не просматривает холст в полном разрешении, вам не нужно переходить от дерева к уровню листа, что дает вам автоматический уровень детализации (LOD).

Некоторые случайные мысли относительнопредлагаемая стратегия

  • Подход quadtree великолепен, поскольку он очень эффективно использует память.
  • Идея потоковой передачи может быть расширена до HDD ... SeaDragon
  • Изощренная реализация потребует чего-то вроде CUDA.
  • Если ваш графический процессор не обеспечивает необходимой производительности / программируемости, просто реализуйте обход на CPU - немного более длительная задержка, пока изображение полностью не отобразится, но должнобыть приемлемым.Не забывайте программировать асинхронно, используя несколько потоков, чтобы экран не зависал при ожидании на процессоре.Вы можете играть с разными эффектами: показывать изображение целиком, сначала размытое изображение и медленно увеличивать детализацию (поиск в ширину (BFS)) или отображать его по частям (поиск в глубину (DFS)) - возможно, смешанный с некоторыми классными эффектами.
  • Программная реализация должна быть довольно простой, когда разрешается только просмотр холста в полном разрешении.Если кто-то может уменьшить масштаб, это небольшое изменение в обходе.Если можно масштабировать плавно, для этого потребуется линейная интерполяция между плитками соседних узлов дерева квадрантов - это уже не тривиально, а выполнимо.
  • Слои: квадродерево должно обеспечивать достаточно низкое потребление памяти, что позволяет просто хранить одно квадродерево.за слой.Но когда у вас много слоев, вам потребуется некоторая оптимизация, чтобы оставаться в режиме реального времени: вы не можете собрать 200 текстур на кадр и отправить их в графический процессор. Может быть (не совсем уверен, является ли это лучшим решением) для каждого слоя, удаляя все узлы квадродеревьев под тем слоем, пиксели плитки которого полностью покрыты слоем выше.Это должно быть сделано во время выполнения, пока требуется рисование и буфер глубины.Если вы предлагаете инструмент ластика, вы не можете удалять узлы, но должны пометить их как «невидимые», чтобы их можно было пропустить во время обхода.

.. с макушки головы.Если у вас есть дополнительные вопросы, дайте мне знать!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...