GDI графика в режиме реального времени

[Dion]

Уже достаточно давно пишу свой проект. Не буду вдаваться в подробности для чего он предназначен, перейдём к части в которой заключается проблема. А именно: есть PictureBox - так называемый "основной экран", на котором рисуются иконки (32х32), связи (линии), текст и геометрические фигуры. Всё это примерно выглядит как рабочий стол Windows, только иконки соединены линиями. И их может быть до 1000 на экране, и столько же линий. Они могут накладываться друг на друга. Механизм работы приложения достаточно прост, есть функция Redraw (перерисовка), есть массивы структур объектов и связей, которые хранят данные объектов, в том числе позицию на экране, какая именно иконка закреплена за объектом и т.д. В "Редраве" всё это дело рисуется обычным проходом цикла по списку структур.
Примерно это выглядит вот так:

Код: Выделить всё

' [*] Функция Redraw
'// [?] Легенда:
'         - iNumObj: кол-во объектов
'         - iNumLines: кол-во связей

'// Объекты
for i = 1 to iNumObj
GdiTransparentBlt данные из массива объектов(i)
TextOut ...(i) '// подпись объекта
'// + рамка для текста и дополнительные "примочки"
Next i

'// Связи
for i = 1 to iNumLines
MoveToEx ...(i)
LineTo ...(i)
Next i


При каких либо изменениях на экране - вызывается функция и перерисовывает всё, например, при таскании объекта мышкой. Кто-то скажет, что перерисовывать ВСЁ - глупо, особенно если изменения происходят только у одного объекта. Но нет, я пытался реализовать - что, только определённые объекты перерисовываются - например, тот, который перемещается и те которых он задел при перемещении, а также примыкающие и задетые линии. Но, а если объектов 200 и пользователь выделил 50 и таскает их? Получались те же тормоза, и пришлось отказаться от этого!
Вот это она и есть, основная проблема - медленность перерисовки в режиме реального времени.
Однократно это рисуется мгновенно, но при "таскании" объекта мышью (задействовано в событии MouseMove - ПикБокса) идёт непрерывная перерисовка, которая здорово тормозит... Причём, чем больше размер PictureBox - тем больше тормоза, в моём случае он занимает почти весь экран в развёрнутом виде *(минус) меню и панель инструментов.

Исследования:
по началу линии текст и фигуры рисовались обычными средствами VB6... Line, Print... Кроме Иконок, которые изначально рисовались двойным BitBlt (+маска прозрачности), который позже был заменён на GdiTransparentBlt. К сожалению, последняя функция в разы медленней, но по заданию, пользователь может сам добавлять иконки с каналом прозрачности по розовому цвету - пришлось отказаться от BitBlt.
Затем Line и Print - были заменены на их GDI-аналоги. Прироста производительности при этом не было. Убирая всё рисуемое кроме иконок - производительность была очень неплохой. Из чего я сделал вывод, что тормоза происходят из-за линий, фигур и текста. Как с этим бороться?
Необходимо чтобы при перемещении объектов они все двигались плавно и без тормозов.

Посоветуйте, пожалуйста, что можно придумать в данной ситуации? Может, есть смысл использовать DirectDraw - но даст ли это желаемой скорости?

[MIT]

Когда нет желания улучшать логику, программисты требуют новые технологии. Яркий пример — IE9: все нормальные браузеры нормально обходятся GDIp`ом, а микросовтовцам лень оптимизировать было, они взяли и перенесли все вычисления на видеокарту и всякие там DirectX`ы и пр..
Так и здесь. Если перенести на DirectDraw, то производительность может быть лучше, однака через задницу можно сделать, использую любую технологию и любые средства разработки.

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

В общем и целом — пересматривай вычислительные алгоритмы.

[FaKk2]

Яркий пример — IE9: все нормальные браузеры нормально обходятся GDIp`ом, а микросовтовцам лень оптимизировать было, они взяли и перенесли все вычисления на видеокарту и всякие там DirectX`ы и пр..

Неожиданное заключение... Мне как пользователю начхать чем обходятся нормальные браузеры. Мне главное что оно быстро работает. Очень быстро.

[Alec]

Обязательно ли пользователю видеть все объекты во время перемещения?
Насколько я помню в Excel (2003 - точно) при перемещении достаточно большого количества объектов они не прорисовываются целиком, а обозначается область, их ограничивающая, а объекты перерисовываются уже после завершения перемещения (отпускания мышки). Тоже позволяет и Windows при перемещении окон - можно отключить прорисовку окна и будет перемещаться только контур.
Может есть смысл сделать аналогично?

[Amed]

Но нет, я пытался реализовать - что, только определённые объекты перерисовываются - например, тот, который перемещается и те которых он задел при перемещении, а также примыкающие и задетые линии. Но, а если объектов 200 и пользователь выделил 50 и таскает их?

А что, если попробовать по-другому?
1. В хранилище 1 (Х1) помещать фоновое изображение + не выделенные элементы
2. В хранилище 2 (Х2) помещать выделенные элементы с маской прозрачности вокруг них
3. При перемещении рисовать в контейнере Х1 + Х2 (с соответствующим смещением)
4. При необходимости перерисовывать переместившиеся линии

Если я ничего не упускаю, то при большом числе объектов больше всего времени будет тратиться на рисование переместившихся линий (Х1, Х2 - зафиксированные единожды растры), а вывод растров будет практически мгновенный.

[Dion]

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

На данный момент реализовано близко к этому... При перемещении от объекта до настоящего положения курсора в реальном времени тянется пунктирная линия (которая показывает откуда и куда переместится объект), при отпускании кнопки мыши объекты перемещаются в нужную точку и однократно перерисовываются. Естественно это всё идеально и быстро работает, но начальник требует от меня, чтобы все объекты и связи таскались за мышкой в режиме реального времени
Кстати если на время непрерывной перерисовки в реальном времени у главного ПикБокса ставить Autoredraw=False, всё это очень быстро рисуется, правда, при этом возникает "эффект жуткого мигания". Поэтому это не годится... На счёт рамок, контуры объектов. (Как я понял вы предлагаете создавать программно массив Shape < со спец. стилем >, которые будут находиться внутри основного PictureBox) Идея очень неплохая, но незнаю как это будет себя вести на деле. Ведь одновременно выделенных объектов может быть больше 100 - 500 на экране...

Если я ничего не упускаю, то при большом числе объектов больше всего времени будет тратиться на рисование переместившихся линий (Х1, Х2 - зафиксированные единожды растры), а вывод растров будет практически мгновенный.

Абсолютно верно!!! Растры перерисовываются очень быстро, даже при 700 объектах на экране всё плавно перемещается. Но стоит только добавить Линии и Текст, как всё начинает страшно тормозить.

У меня была неплохая идея, но она не сработала из-за особенностей совместимости API-функций. Я сделал отдельную форму, задав ей родительским PictureBox. На этой форме рисовались объекты (которые выделены и их возможно будут перемещать), фон формы заливался цветом, который задавался прозрачным. Всё бы прекрасно, но эти 2 API функции оказались совместно несовместимы. Вместе они работали через "жо..."
Я решил делать без родительского окна... Но прозрачная форма с объектами начала гулять по всему экрану, я смог её корректно ограничивать в пределах ПикчуреБокса и пришлось отказаться от этой идеи

Вообще вся загвоздка кроется в связях, которая не даёт оптимизировать перерисовку каких-то конкретных элементов. Дело в том что по архитектуре, сначала рисуются все связи, а потом на них накладываются объекты. И часто бывает так, что от всех объектов идут связи к одному (основному) и скорее всего двигать будут именно его! А сдвинув его, это затрагивает всё что есть на экране... Тут не избежать перерисовки каких-то отдельных элементов

[Adam Smith]

Ну если растр рисуется быстрее текста, то может заготовить сразу рисунки всех надписей?
Не совсем понял про иконки, но рисовать 32х битные можно просто DrawIcon DrawIconEx.

[Sam777e]

Не знаю - актуальна ли ещё проблема; и не вникал в Ваше решение и советы коллег. Однако, вопрос: когда и как часто Вы вызываете Redrow? Если по MouseMove, то рекомендую вызывать НЕ ПО КАЖДОМУ событию, а, скажем, по 20-ому, 40-ому, и.т.д.
С уважением.

[FireFenix]

Не знаю - актуальна ли ещё проблема; и не вникал в Ваше решение и советы коллег

Зачем работать археологом и не смотреть на пройденный путь?

Redrow

ReDraw

Если по MouseMove, то рекомендую вызывать НЕ ПО КАЖДОМУ событию, а, скажем, по 20-ому, 40-ому, и.т.д.

Дёргание объекта ~ Fail

[Sam777e]

Ещё раз просмотрел всё - и снова рекомендую обратить внимание на ЧАСТОТУ обращения к ReDraw

[c0de_in]

а не проще создать один маленький пикчербокс с нулевым индексом а в рантайме уже создавать нужное кол-во объектов функцией load?

[Yabloko9393]

Если по MouseMove, то рекомендую вызывать НЕ ПО КАЖДОМУ событию, а, скажем, по 20-ому, 40-ому, и.т.д.

Дёргание объекта ~ Fail
ИЗВИНИТЕ....я конечно полный профан, но с подобной проблемой сталкивался....Перерисовывать надо не в событии движения мыши, и не через 20-40 прикселей перемещения мыши....когда начинаем тащить че-нибуть то Flag=да =)))...и ксли этотFlad=да, то таймер через каждые скажем 30 силисекунд вызывает перерисовку....ниче не дергается(если конечно успевает за это время все перерисовать)....это я когдато через по*у строил графики с обнаружением точек разрыва, благодаря таймеру получается гораздо лучше......Не замечали, когда рабочий стол завис, а мы таскаем окно, то от него следы остаются, но они остаются не через каждый пиксель и не через 20-40...а ровно через определенный промежуток времени

[meh&vb]

Мне кажется, если в качестве рисунков(иконок) и объектов(текста и фигур...) использовать готовые контролы, а потом, выделив их, таскать по PictureBox, то это будет быстрее. Но вот перемещаться будет только контур выделенных фигур, а сами объекты только после отпускания мышки(запомнить все контролы в массиве, а затем просто изменить их координаты).

[ark]

Autoredraw=False, всё это очень быстро рисуется, правда, при этом возникает "эффект жуткого мигания"

Субклассинг на пропуск WM_ERASEBKGND должен помочь

[burik]

Уважаемое сообщество некрофилов, вы поднадоели за последнее время.