При вызове функции GetDC() генерируется сообщение WM_PAINT. В Windows этого нет.
Илья: В первую очередь стоит написать тест в 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-ами.
