Редактировалось 3 раз(а), последний 2021-05-22 09:25:45

ExampleOpenGl*.sha

Редактировалось 3 раз(а), последний 2021-05-22 09:25:45

Dilma, не плохо былобы создать раздел посвещеный OpenGL.

для чего? схемы с использованием opengl выкладывает только один человек у нас

А еще неплохо БЫ сделать рисование, как положено в винде - по WM_PAINT, а не "по таймеру на хэндле".
Invalidate может ведь не только по KOL-овским onMouseEnter/Leave прилететь...
Винда его имеет право прислать в любой момент, никого не спрашивая.

Таская, например, чего ни то перед мордой примеров из папки OpenGL - можно спокойно наблюдать артефакты
По той же самой причине... Чем медленней таймер, тем заметнее артефакты.

dynamic-95-188-164-72.ppp, в пору когда разбирался с основами OpenGL, возникала попытка завести тему где каждый мог-бы выложить простые схемы с пошаговым описанием. Но увы проект зачах, кто-то кого-то непонял .
http://hiasm.1gb.ru/forum.html?q=3&p=91935
Galkov, если можно ещё пару слов в чём выражен артефакт? уж чего я по экрану не таскал .
Единствено что заметил это срезание картинки.

MAV, артефакт выражается в том, что WM_PAINT системный и Flip от OpenGL рассинхронизорованны и поэтому при некоторых обстоятельвах может быть заметно мигание. Однако... прошу заметить, что если в кодах библиотеки KOL есть методы, которые вызывают Invalidate элемента с перезаливкой фона (onMouseEnter/Leave именно этим и балуются), то исправить этот момент не возможно никак кроме перекрытия WM_ERASEBACKGROUND (вроде так сообщение звучит), что вообще говоря есть костыль.

Вот простой пример такого гадского Invalidate
code_13063.txt

однако если переписать RedrawManager вот так
мы получим как раз то, что нужно


насколько мне известно от системы никогда не приходят сообщения с требованием перерисовать фон, кроме как при изменении габаритных размеров окна. В этих случаях любое приложение будет мигать, что прекрасно видно на игре(под DirectX или OpenGL не важно) свернутой в оконный режим

Не только. На топе может быть не только наша форма. Манипуляции с другой формой (обозначенные ранее как "таскание чего ни то перед мордой") вызывают поток рисовательных событий и на нашей. Которые мы (по всем правилам) обязаны правильно отработать, не взирая на состояние нашего таймера.

Но даже не в этом дело.
Есть правило в винде: ты обязан быть готов в любую секунду нарисовать то, чего там должно быть на самом деле.
Костыльное оно или нет, а ничего тут уж не поделаешь.
Если мы научим пользователя следовать этому правилу, то остальная ответственность за качество рисования - уже за виндой.
Если научим нарушать - это будет не очень правильно.
Независимо от того, хотят пользователи, чтобы об них заботились, или не хотят, а заботиться - следует (некоторым и так не дует).

Есть вещи, которых я не знаю. К таковым относятся, например, OpenGL. Остается ли после flip-а "в запасном буфере" то, чего было ранее, или его надо творить заново - не знаю.
Но то, что знаю - знаю надежно.
Правильно (это то, что я знаю надежно) - по таймеру (или по другим интерфейсным событиям) менять рисунок OpenGL-модели в буфере, и делать invalidate (не важно в каком порядке, естественно). А по WM_PAINT (который является следствием не только нашего invalidate) кидать содержимое буфера "на показ".
И с WM_ERASEBKGND наша обязанность разобраться, если хотим рисовать на форме, а не на панели (у класса BUTTON в default-е оно ничего не делает)
Хоть костыль, хоть нет, а деваться некуда. Можно всю винду назвать одним большим костылем, если уж очень сильно призадуматься.

Скажем, то "баловство" Кладова с onMouseEnter/Leave
Не тот он человек, чтобы без причин лишние коды ставить. Следовательно, причины были. И достаточно серьезные, даже если мы о них и не знаем - "на всякий случай" он ничего не делает.
Я в деталях очень-то не разбирался, но оценил возможность доказать ему, что он дурак -- как совершенно бесперспективную. Потому-что он не дурак, и "правила рисования" не хуже нашего знает.

Да, были, когда-то, подмигивания при MainForm.Picture<>0. Этот вопрос (в отличие от OpenGL) я знаю, и поэтому этой проблемы просто нет. Давно уже.

ну так предложенный выше пример как раз и реагирует на любые перерисовки из вне.

Неправда. Система всегда посылает сначала WM_ERASEBKGND, а потом уже WM_PAINT. Многие программы, чтобы не мигать, делают всю отрисовку по WM_ERASEBKGND, а на WM_PAINT плюют, т.к. последний может быть послан гораздо позже, чем обнаружилась необходимость перерисовки (когда процессор сильно загружен, винды не торопятся делать WM_PAINT).

это поведение настраивается флагами при создании окна. Вот небольшая статейка по этому вопросу
http://www.delphisources.ru/pages/faq/base/drawing_without_twinkling.html

Ну да, если указать WS_EX_TRANSPARENT, то WM_ERASEBKGND посылаться не будет, НО! будет отрисовано содержимое под окном.

tsdima, ну а если все-таки ближе к телу (как говаривал Мопосан)

Есть сегодня элементная база на OpenGL
Она предполагает получение хэндла от некого окна. Ничего не предполагая он его стилях, и т.п..
Какие есть варианты:
1) Если изменить эту постановку, то будут проблемы совместимости.
2) Можно делать хук через Set/GetWindowLong. Тогда, на какое сообщение садиться, или на оба - просто мелкие технические подробности.
3) Можно ничего не делать.

Ну вот и скажи мне как гинеколог гинекологу: какой вариант тебе больше по душе. И есть еще какой другой вариант

Мне, как гинекологу, всё равно, т.к. я этим пока не пользуюсь. Учитывая, что большинство OpenGL программ обновляют окно 50 раз в секунду, можно ничего не делать. Если делать хук, то достаточно перехватывать WM_ERASEBKGND (или WM_PAINT если у окна стоит стиль WS_EX_TRANSPARENT). А Redraw делать как обычно, не отменяя WM_ERASEBKGND.