Bug 1949

Илья:
В первую очередь стоит написать тест в user32:msg, чтобы убедиться, что это сообщение лишнее во всех случаях, а не для конкретного стиля окна..

lav:
Стоит обратить на это внимание, может увеличить производительность при работе через nx-клиент.

Илья, какие-нибудь результаты исследования есть? Стоит в багу записывать результаты и наблюдения.

Возможное решение, найденное случайно - убрать вызов SelectVisRgn в ф-ции update_visible_region (painting.c:166). 
В результате WM_PAINT вызывется при старте приложения только 1 раз вместо 2х или 3х.
Сейчас пишу тест.

Есть тест. 
Лишнее WM_PAINT генерируется для WS_OVERLAPPEDWINDOW, WS_TILEDWINDOW, WS_POPUPWINDOW (только когда WS_MAXIMIZE), WS_CHILD (только WS_MAXIMIZE).
Для любых WS_MINIMIZE окон лишнего WM_PAINT нет.

(In reply to comment #4)
> Есть тест. 
> Лишнее WM_PAINT генерируется для WS_OVERLAPPEDWINDOW,
> WS_TILEDWINDOW, WS_POPUPWINDOW (только когда WS_MAXIMIZE), WS_CHILD
> (только WS_MAXIMIZE).
> Для любых WS_MINIMIZE окон лишнего WM_PAINT нет.
> 

Хорошо, тогда нужно его отослать в wine-patches.

В WINDOWS все тесты проходят. Т.е. никаких лишних WM_PAINT нигде нет.

(In reply to comment #6)
> В WINDOWS все тесты проходят. Т.е. никаких
> лишних WM_PAINT нигде нет.
> 

А в Wine-то есть?

Да в WINE есть. Но пока не совсем понятно почему. Может быть GetDC и не причем. Надо разобраться с этим.

Есть идея, точнее предположение, почему появляются лишние WM_PAINT.
Ф-ция GetDCEx вызывает update_visible_region, которая в свою очередь вызывает SelectVisRgn. Вся проблема в этой SelectVisRgn. Дело в том, что когда в этой функции переменной dc->hVisRgn присваивается новое значение WINE решает послать WM_PAINT и перерисовать клиентское окно.
Поэтому решить эту проблему можно, если делать проверку - пустое значение dc->hVisRgn или там что-то есть. Если что-то есть - новое значение не присваивать.

(In reply to comment #9)

> Поэтому решить эту проблему можно, если
> делать проверку - пустое значение dc->hVisRgn
> или там что-то есть. Если что-то есть - новое
> значение не присваивать.
> 
Хорошая идея, главное, чтобы она подтверждалась тестами и посмотри ещё новые исходники - руководитель проекта сделал несколько патчей как раз на регион.

С моей идеей тесты проходят. 
Посмотрел последние патчи Виталика за 23.06 - тесты также падают как раньше. 
Я тогда делаю 2 патча - на тесты и на fix.

(In reply to comment #11)
> С моей идеей тесты проходят. 
> Посмотрел последние патчи Виталика за 23.06 -
> тесты также падают как раньше. 
Нет, я имел ввиду патч руководителя open source проекта:
http://source.winehq.org/git/wine.git/?a=commit;h=0f9484a1240fdc4d95e53b3a3b7c13a02b608a78

> Я тогда делаю 2 патча - на тесты и на fix.
> 
Проверь, пожалуйста, ещё раз и после этого делай fix :)

Если патчи примут, то закрой багу. Если нет, то её стоит переоткрыть.

Тест не приняли:
There isn't even a GetDC call in that test. Most likely all you are
seeing is that expose events generate WM_PAINT, which is as it should
be. What are you trying to test?

Created attachment 690 [details]
WindowTest.exe

Тестовый пример. 
Показывает сколько сообщений WM_PAINT генерируется при создании чистого окна, его сворачивании и максимизации/минимизации.

В не managed режиме при создании окна посылается только одно сообщение WM_PAINT (как и в windows).

Думаю, в приложения с отрисовкой не по WM_PAINT и возникающими из-за этого проблемами стоит использовать не managed режим. Вряд ли получиться убрать сообщения WM_PAINT связанные с X-ами.