А не знает-ли кто, господа, как оптимизировать графический вывод в View. А то скролинг страшный как война с Иракаом.
Если на прямую выводить, то мигает как аварийная сигнализация, а если сначала в память а потом BitBit, то тормозит страшно. Если бы вот как в Excel...И как им это удается?
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
Здравствуйте, Gregory, Вы писали:
G>А не знает-ли кто, господа, как оптимизировать графический вывод в View. А то скролинг страшный как война с Иракаом. G>Если на прямую выводить, то мигает как аварийная сигнализация, а если сначала в память а потом BitBit, то тормозит страшно. Если бы вот как в Excel...И как им это удается?
Общая рекомендация — делать поменьше тупой работы.
А именно:
— При скроллинге как правило шлется куча сообщений — и далеко не при всех сообщениях надо вызывать перерисовку. Ты сначала вычисли положение сколлера, а потом посмотри, может оно совпадает с текущим — и только потом давай команду на перерисовку.
— Чтобы вызвать перерисовку вызывай InvalidateWindow и только. Не надо извращаться с RedrawWindow и прочей мутью.
— При перерисовке надо перерисовывать — и только. Если ты в процессе перерисовки ведешь какие-то более или менее трудоемкие расчеты, делай их где-нибудь в другом месте.
____________________
God obviously didn't debug, hasn't done any maintenance, and no documentation can be found. Truly amateur work.
Здравствуйте, TepMuHyc, Вы писали:
TMH>- При скроллинге как правило шлется куча сообщений — и далеко не при всех сообщениях надо вызывать перерисовку. Ты сначала вычисли положение сколлера, а потом посмотри, может оно совпадает с текущим — и только потом давай команду на перерисовку. TMH>- Чтобы вызвать перерисовку вызывай InvalidateWindow и только. Не надо извращаться с RedrawWindow и прочей мутью. TMH>- При перерисовке надо перерисовывать — и только. Если ты в процессе перерисовки ведешь какие-то более или менее трудоемкие расчеты, делай их где-нибудь в другом месте.
Все выше изложеное изначально было принято во внимание. Вконце скролинга(если действительно необходима перерисовка) вызывается
Invalidate(FALSE);
OnPaint();
Вычисления действительно производятся, но исключительно целочисленные и их не много. Дело в том, что тормозят, похоже, как-раз функции CDC.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
G>Вычисления действительно производятся, но исключительно целочисленные и их не много. Дело в том, что тормозят, похоже, как-раз функции CDC.
В подтверждение своих слов привожу результаты измерений:
Full time: 191 Paint time: 120
Full time: 332 Paint time: 182
Full time: 311 Paint time: 180
Full time: 321 Paint time: 211
Full time: 332 Paint time: 192
Full time: 331 Paint time: 200
Full time: 332 Paint time: 202
Full time: 341 Paint time: 181
Full time: 352 Paint time: 232
Full time: 332 Paint time: 242
Здесь "Full time" общее время выполнения функции OnPaint() в клоках, а "Paint time" время потраченое собственно на отрисовку, а имено — на вызов двух функций Rectangle и DrawText.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
Здравствуйте, Gregory, Вы писали:
G>>Вычисления действительно производятся, но исключительно целочисленные и их не много. Дело в том, что тормозят, похоже, как-раз функции CDC.
G>В подтверждение своих слов привожу результаты измерений: G>
G>Здесь "Full time" общее время выполнения функции OnPaint() в клоках, а "Paint time" время потраченое собственно на отрисовку, а имено — на вызов двух функций Rectangle и DrawText.
Похожий вопрос как то поднимался. Поищи.
Совет: НЕ ИСПОЬЗУЙ DrawText
Вместо нее можно например взять ExtTextOut и доработать самому
Здравствуйте, Gregory, Вы писали:
G>А не знает-ли кто, господа, как оптимизировать графический вывод в View. А то скролинг страшный как война с Иракаом. G>Если на прямую выводить, то мигает как аварийная сигнализация, а если сначала в память а потом BitBit, то тормозит страшно. Если бы вот как в Excel...И как им это удается?
А мигает, потому что сначала все окно закрашивается кистью с цветом фона, а уже потом происходит собственно вывод всего остального.
Что бы от этого избавиться есть два способа.
1) Перехватывать WM_ERASEBKGND и там ничего не делать.
2) При регистрации оконного класса установить параметр hbrBackground в NULL.
Здравствуйте, Всеволод, Вы писали:
В>А мигает, потому что сначала все окно закрашивается кистью с цветом фона, а уже потом происходит собственно вывод всего остального. В>Что бы от этого избавиться есть два способа. В>1) Перехватывать WM_ERASEBKGND и там ничего не делать.
Перехватывается, и что-то делается при необходимости. Мигает из-за крайне медленой отрисовки.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
Согласен, ляпа. Искоренил, но скорости это ощутимо не добавило, т.к. после вызова Invalidate(FALSE); клиент окна становился валидным и OnPaint(); фактически ничего не делала.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
Здравствуйте, Gregory, Вы писали:
G>>Вычисления действительно производятся, но исключительно целочисленные и их не много. Дело в том, что тормозят, похоже, как-раз функции CDC.
G>В подтверждение своих слов привожу результаты измерений: G>
G>Здесь "Full time" общее время выполнения функции OnPaint() в клоках, а "Paint time" время потраченое собственно на отрисовку, а имено — на вызов двух функций Rectangle и DrawText.
Попробуй вместо того, что бы рисовать прямоугольники вызовом Rectangle, сначала сформировать координаты углов всех прямоугольников, а потом отрисовать их все за один раз вызвав PolyPolygon.
Здравствуйте, Всеволод, Вы писали:
В>Здравствуйте, Gregory, Вы писали:
В>Что бы от этого избавиться есть два способа. В>1) Перехватывать WM_ERASEBKGND и там ничего не делать. В>2) При регистрации оконного класса установить параметр hbrBackground в NULL.
Проходили мы все это. У меня другой прикол. На "дохлой" машине P3 400Mhz
"летает", а вот на 1,5Ghz строки во View при скроллинге как бы размазываются .
Кто бы мне все это объяснил? Упарился уже.
Здравствуйте, Всеволод, Вы писали:
В> В>Попробуй вместо того, что бы рисовать прямоугольники вызовом Rectangle, сначала сформировать координаты углов всех прямоугольников, а потом отрисовать их все за один раз вызвав PolyPolygon.
Поясняю. Изображивается сетка(таблица) а-ля Excel. Каждая клетка может иметь собственные атрибуты (цвет фона, толщину рамки и т.п).
Поэтому PolyPolygon не прокатывает.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
Здравствуйте, Gregory, Вы писали:
G>Здравствуйте, Всеволод, Вы писали:
В>> В>>Попробуй вместо того, что бы рисовать прямоугольники вызовом Rectangle, сначала сформировать координаты углов всех прямоугольников, а потом отрисовать их все за один раз вызвав PolyPolygon.
G>Поясняю. Изображивается сетка(таблица) а-ля Excel. Каждая клетка может иметь собственные атрибуты (цвет фона, толщину рамки и т.п). G>Поэтому PolyPolygon не прокатывает.
Здравствуйте, Gregory, Вы писали:
G>Здравствуйте, Всеволод, Вы писали:
В>>Может все-таки код покажешь ?
G>
G>void CGridView::OnPaint()
G>{
skipped
G>}
G>
Некоторые вещи приходят на ум...
1) Контекст памяти можно сделать один раз, не нужно его формировать при каждом вызове функции OnPaint.
Кстати сделать его можно и в другой функции.
2) То же самое касается и Bitmap. Сделай ее один раз максимально возможного размера.
Как мне понимается, максимальный размер окна может быть не больше текущего разрешения desktop'а.
Вот такого размера и должна быть bitmap.
3) Зачем ты делаешь SaveDC()/RestoreDC() ?
4) Поясни, пожалуйста, что у тебя там со стиранием происходит ?
Самая первая напрашиваемая оптимизация — сделать dcMem переменной CGridView и создать его только один раз — сразу при создании окна. То же самое с битмапом, но пересоздавать его по WM_SIZE с учётом нового размера клиентской области. И с фонтами и перьями можно сделать аналогично — сделать для них кэш — ведь, скорее всего, количество используемых фонтов намного меньше ячеек.
[]
В>1) Контекст памяти можно сделать один раз, не нужно его формировать при каждом вызове функции OnPaint. В> Кстати сделать его можно и в другой функции. В>2) То же самое касается и Bitmap. Сделай ее один раз максимально возможного размера. В> Как мне понимается, максимальный размер окна может быть не больше текущего разрешения desktop'а. В> Вот такого размера и должна быть bitmap.
Здравствуйте, Patalog, Вы писали:
P>Здравствуйте, Всеволод, Вы писали:
P>[]
В>>1) Контекст памяти можно сделать один раз, не нужно его формировать при каждом вызове функции OnPaint. В>> Кстати сделать его можно и в другой функции. В>>2) То же самое касается и Bitmap. Сделай ее один раз максимально возможного размера. В>> Как мне понимается, максимальный размер окна может быть не больше текущего разрешения desktop'а. В>> Вот такого размера и должна быть bitmap.
P>+ то же самое насчет шрифтов
А я так понял, что шрифт не фиксированный и у каждой ячейки он может быть свой.
Если количество используемых шрифтов ограничено, то тогда клнечно имеет смысл и их сформировать один раз и на всегда.
Здравствуйте, Всеволод, Вы писали:
В>1) Контекст памяти можно сделать один раз, не нужно его формировать при каждом вызове функции OnPaint. В> Кстати сделать его можно и в другой функции. В>2) То же самое касается и Bitmap. Сделай ее один раз максимально возможного размера. В> Как мне понимается, максимальный размер окна может быть не больше текущего разрешения desktop'а. В> Вот такого размера и должна быть bitmap.
Все это совершено верно, но если вернуться к моему посту с анализом времени выполенеия всей функции и отрисовки, то станет ясно, что клоков 10-20 на этом сэкономить можно, но кардинально это проблему не решит. В>3) Зачем ты делаешь SaveDC()/RestoreDC() ?
Машков с Тихомировым попутали.
В>4) Поясни, пожалуйста, что у тебя там со стиранием происходит ?
Закрашивается незанятая сеткой часть клиента.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг
Здравствуйте, Gregory, Вы писали:
G>Все это совершено верно, но если вернуться к моему посту с анализом времени выполенеия всей функции и отрисовки, то станет ясно, что клоков 10-20 на этом сэкономить можно, но кардинально это проблему не решит.
Проведенный эксперимент подтвердил истиность предыдущих строк.
Не дай своим глазам увидеть, а ушам услышать то, что ты не сможешь объяснить.
Абрахам ван Хелсинг