Название темы - перефразировка понятия "dll hell". Это из области .Net, когда обращают внимание на большое количество dll, находящихся в системе, имеющих разные версии, конфликтующих друг с другом и вообще мешающих жить. Разработчики .Net считают, что разобрались с этой проблемой, ну да не о том речь. А речь, собственно, о тех проблемах, которые создает необходимость обработки сообщения wm_paint (прочих тоже, но в гораздо меньшей степени).

Итак, сначала описание проблемы. Допустим, у нас есть окно, и мы хотим там что-то нарисовать. В Форте, разумеется. Надо вводить команды PIXEL CIRCLE LINE RECTANGLE и прочие? Нет, все совсем не так просто. Конечно, нарисовать-то можно, вот только жить этот рисунок будет до первого смещения окна по экрану, перетаскиванию поверх него другого окна и вообще до первой обработки сообщения wm_paint. Это сообщение посылается окну, когда оно должно перерисоваться, и вот тут-то и зарыта собака. Ведь мы никак не модифицировали обработчик wm_paint, и рисунок просто пропал. Кстати, пример с "пропадающим" текстом есть даже в Win32Forth. В справке честно предупреждают, что текст вывести можно, но после перерисовки его в окне уже не будет. Решение проблемы очевидно - надо написать в обработчике порядок действий по рисованию содержимого окна.

Вот тут и начинается собственно hell. Обработчик один, а вариантов содержимого экрана много. Программа вообще развивается, усложняется и живет своей жизнью в процессе разработки. И сидеть программисту в редакторе с открытым обработчиком wm_paint, то есть в самой ответственной части windows-приложения - обработчике сообщений. Там тоже не все просто - надо получить контекст рисования, нарисовать (внутри BeginPaint/EndPaint), освободить контекст. Контекст - это ресурс (а значит, если забудем освободить - имеем утечку ресурсов). Об интерактивной работе тоже не может быть и речи - обработчик нельзя перекомпилировать "на живую". Общий стиль работы соответствует чистому API графической системы Windows - вызов системных функций "вручную". Такой стиль предлагался еще в Borland Pascal 7.0 for Windows и Borland C 3.1 for то же самое. Старый стиль, вобщем. Кстати, в литературе по тем продуктам он рассматривался уже наряду с объектно-ориентированным подходом (OWL). Наконец, на смену пришли визуальные системы, например Delphi. В Delphi программист может ничего не знать о системных сообщениях, потому что в общем и целом надо сделать одно - скопировать некую область с рисунком в окно программы. Существует и специальный компонент - Canvas, представляющий собой массив точек. Программист может поставить на Canvas точку и забыть о ее существовании - обработчик wm_paint возьмет Canvas и скопирует его в окно. Конечно, мелкие рисунки отрисовать вручную было бы гораздо быстрее по сравнению с копированием большой прямоугольной области, зато удобно тем, что можно просто поставить Canvas.Pixels[100,100] = clRed в любой процедуре.

Кстати, вот еще один вариант обработчика wm_paint.



То есть имеется массив screen, куда можно просто записать что-то в формате RGBA. Отрисовкой занимается само окно, копируя screen на поверхность OpenGL. Собственно, можно было бы и DirectX, и функции GUI, но так уж получилось

Хм...



~profit\prog\browser\layout.f

С самого начала отделил отрисовщик от всех остальных модулей. Самый простой модуль:




Изначально у меня был только блок "Отрезок". Потом добавлял "Рисунок", "Рамка" и остальных.

Были некоторые проблемы с прокруткой, когда макет "мелькал", но кажется проблему заборол (не помно точно, надо свериться с дневником разработки).

Напоминаю, что речь идет о постоянной работе с графикой. Отрисовка в браузере - это не постоянная работа. Это пишется при разработке самого браузера. А вот попытаться сделать на таких принципах графический редактор уже не получится.

Если графический редактор -- векторный, то получится. Но да, согласен. Хотя я тут не в теме, по ощущениям говорю...

Да, когда объектов станет много, проще будет просто копировать попиксельно. Что, собственно, и предлагается.

Смотря какое событие... Насколько я что-то понимаю, кол-во обсчитываемых объектов всегда уменьшается к необходимому минимуму (как и в 3d, есть алгоритмы скрытых фигур).

WM_PAINT передаёт как-то (не помню) ту область которую и надо обновлять, необязательно это всё окно (экран). Можно считать только её.

Но да, без двойной буферизации -- никуда. То есть можно теоретически, но как на практике -- не в курсе...

Вот это и есть hell Хорошо, когда мы пишем программу, которая будет выводить что-то при своей работе, тут можно обратить внимание на разные аспекты. А мне вот постоянно надо рисовать графики, причем как в 2D, так и в 3D. И я совершенно не хочу каждый раз лезть в wm_paint и что-то там править, с риском развалить вообще все приложение. Кроме того, интерактивный режим. И это не просто так, это, к примеру, когда после недельного расчета требуется наглядно представить полученные данные и по итогам либо продолжать, либо прекратить. И что, сохранять вообще все данные, выходить, писать программу просмотра графика, запускать, подгружать данные...? По сравнению с ДОСовскими трансляторами - ужасно неудобно.



Очень редко. Восстановление из минимизированного состояния, перемещение по экрану, выход на передний план после того, как окно было полностью закрыто - это все требует полной отрисовки. Оптимизация по частичной отрисовке годится разве что для ситуаций, когда при каждом wm_paint происходит рендеринг всей сцены. А это уже трехмерные пакеты, и вообще непонятно, почему тот же Matlab не рендерит в буфер трехмерные графики. Вобщем, тут экономия копеечная, потому что я даже при постоянных пересылках по 4 Мб в буфер вообще не замечаю никаких тормозов.

Если работать только с Win32 GDI, то есть ещё один подход. Можно создать Device Context в памяти и при интерактивном рисовании - рисовать в него. А в WM_PAINT просто сделать копирование из memdc в dc на экран. Смотрите например в ~ygrek/prog/ulam/ulam.f слова CreateMemDC, ClearMemDC и заметьте что всё рисование (в частности pixel) делается с хэндлом memdc. А настоящеее рисование происходит в

Можно назвать по меньшей мере три подхода, в зависимости от используемой графической библиотеки. Это вывод средствами GDI, через DirectX, или через OpenGL. Промежуточный буфер в памяти присутствует во всех случаях. Вопрос только в том, что GDI довольно медленная вещь, а DirectX (точнее, DirectDraw) - довольно навороченная, сложнее в использовании и ориентирована в основном на игровую графику. С OpenGL работать гораздо приятнее, и качество трехмерной графики будет повыше.

Если рисовать OGL по WM_PAINT, то большой скорости всё равно не получить. Вариант - рисовать без WM_PAINT и в отдельном потоке.

Стоп-стоп! О чем речь-то? Пока никто в OGL вообще не лезет - есть же массив screen. Это еще одна прослойка по отношению к буферам OGL. Вопрос только в том, что отрисовка поверхности сводится к копированию из обычного массива в память, отвечающую за экранный буфер. Тут уж извините, быстрее просто не получится, точки-то надо проставить так или иначе. Разумеется, в процессе отрисовки никакого обновления экрана не происходит. В OGL скрипт рисования все равно обрамляется вызовами BeginPaint / EndPaint, поэтому лишних операций с экранной памятью тоже нет. Ну и наконец, я сравниваю вывод текста через OpenGL с выводом текста в консоль Win32Forth (средствами GDI, очевидно). "Почувствуйте разницу" - отрисовку экрана у себя я просто не замечаю, а в Win32Forth оно еле-еле ползет (и это на GF6600!).