Как рисовать не в paintEvent?

[lit-uriy]

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

подобная ситуация возникает например при построении графика. Есть такая библиотека Qwt, можно наверняка глянуть её исходники.

Я не замечал существенных тормозов на динамически обновляемых графиках в их примерах.

[marty]

>>Вы бы лучше приведенный код попинали, вместо ёрничания.
ну я тебе ссылки давал, во втрой ссылке  как раз расматривается вопрос рисования не в paintEvent

За ссылки спасибо, правда это не совсем то, что нужно. То, что нужно, пришлось самому написать

[BRE]

По-моему, данное ограничение по рисованию только во время paintEvent довольно большой недостаток, которого нет у WinAPI (и его оберток) и у wxWidgets.

Рисовать на большинстве PaintDevice можно в любой момент, а вот рисовать на виджете можно только в paintEvent. Кстати как и в WinAPI и у wxWidgets (если мне память не изменяет). 

Я бы с удовольствием, но надо на плюсах, да так, чтоб работало с WTL, wxWidgets да с Qt. С последним постоянно какой-то гемморой возникает, в отличии от первых двух библиотек.

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

[marty]

По-моему, данное ограничение по рисованию только во время paintEvent довольно большой недостаток, которого нет у WinAPI (и его оберток) и у wxWidgets.

Рисовать на большинстве PaintDevice можно в любой момент, а вот рисовать на виджете можно только в paintEvent. Кстати как и в WinAPI и у wxWidgets (если мне память не изменяет). 

С wxWidget по этому вопросу еще не разбирался, а в винде можно рисовать в любой момент. Есть только небольшое отличие - контекс HDC надо получать через BeginPaint (в обработчике WM_PAINT) или GetDC в остальных случаях.

[Авварон]

контекст устройства это вообще ппц... перегрузка пейнт эвента гораздо проще и адекватнее выглядит

[marty]

контекст устройства это вообще ппц... перегрузка пейнт эвента гораздо проще и адекватнее выглядит

А чего тут ппц? В paintEvent'е все равно используется контекст рисования, а как он называется, HDC, wxDC или QPainter, это по-моему не принципиально.

[Авварон]

эти классы имеют _разный_ смысл. контекст устройства - непонятная примочка, нафиг откуда мне взявшаяся. qpainter - класс-рисовальщик. А всякие bitblt это вообще вынос мозга...

[break]

Прочитал тему с самого начала!
Не пойму одного почему автор не хочет рисовать в PaintEvent - даже если предположить что в Qt с этим проблемы - зачем не использовать то подо что в Qt все рисования и затачивались. Кроме того контекст QPainter - сильно от личается от других контекстов- он имеет кучу доп. возможностей - например трансформации(scale, rotate и др.).

[fuCtor]

Заходя на форум хотел создать почти такой же топик.

Автора топика очень даже понимаю. самого интересует вопрос как бы ускорить вывод порядка тысячи полигонов с переключением стилей  и тд. По замерам на отрисовку окна 1024 на 768 на котором помещалось порядка пары тысяч полигонов уходило порядка секунды. Отрисовку выполнял в буфер а только потом вывод буфера на бэкграунд GraphicsView.
Скорость явна маленькая и неприемлимая. При том что под WinAPI удалось точно такой же код разогнать до 300мс. Вознивает вопрос. Что не так делаю и куда копать чтоб ускорить отрисовку. Буфер используется для частичной перерисовки при смещении., путем дорисовки необходимого.

[ufna]

вопрос - а стили и т.п., да и сами полигоны на поле у тебя динамичные или статичные?

[fuCtor]

статичны и хранятся в дереве (полигоны). Стили тоже статичны. Если загрузить ВСЕ полигоны в виде GraphicsItem то это cъедает не мало памяти. Если фрагментами, то нарушается порядок следования (z-order). Судя по профайлеру то 80% времени съедает вывод именно полигонов, а не смена стиля рисования.

[ufna]

а можно сам код отрисовки глянуть?

[fuCtor]

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

а сама отрисовки сводится к:
- вывод обычных полигонов + плюс накопление для отложенного вывода при определенных условиях
- обработка списка отложенных полигонов
- вывод их

[ufna]

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

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

[fuCtor]

Полученный буфер потом выводится на QGV и поверх него еще элементы интерфейса рисуются (QGI).
Оптимизировал алгоритм, стало все очень даже прилично ) Осталось с надписями разобраться, раза в 3 4 просаживают.
Для дополнительной оптимизации вобще думаю переписать paintEvent у QGV (взять его родной и убрать оттуда буфер фона, заменив его на свой).

А код в итоге не разрешили показывать мол коммерческая тайна...