Если в 1с открыть несколько окон, то при открытии каждого следующего все остальные окна последовательно выходят на передний план, и это заметно тормозит интерфейс пользователя. Ваня, проверь пожалуйста как это на Windows происходит (может быть специально нагрузить машину, чтобы увидеть). Хочется понять, это Wine медленно перерисовывает, или принципиально неверно что он начинает их всех обновлять. Насколько я помню, проблема только при переключении в развёрнутом виде, потому что при переключении окно сворачивается, а потом разворачивается обратно...
В Windows переключение между окнами происходит нормально. Значит ошибка wine.
Такая же ошибка замечена в программе SigTreader 4.(так как там работа идет с графиками, то это очень сильно тормозит программу)
Заценил, буду делать..
Это проблема в реализации MFC.
trace:mdi:DefMDIChildProcA 0x100c0 0046 (WM_WINDOWPOSCHANGING) 00000000 0034da7c trace:mdi:DefMDIChildProcA 0x100c0 0083 (WM_NCCALCSIZE) 00000001 0034d9b8 trace:mdi:DefMDIChildProcA 0x100c0 0047 (WM_WINDOWPOSCHANGED) 00000000 0034da7c trace:mdi:DefMDIChildProcA 0x100c0 0003 (WM_MOVE) 00000000 00430030 trace:mdi:DefMDIChildProcA 0x100c0 0005 (WM_SIZE) 00000000 01aa0416 trace:mdi:DefMDIChildProcW 0x100c0 0005 (WM_SIZE) 00000000 01aa0416 trace:mdi:DefMDIChildProcW current active 0x100a8, maximized (nil) trace:mdi:DefMDIChildProcA 0x100c0 0368 (WM_RECALCPARENT) 00000000 0034b490 trace:mdi:DefMDIChildProcA 0x100c0 0005 (WM_SIZE) 00000000 01aa0416 trace:mdi:DefMDIChildProcW 0x100c0 0005 (WM_SIZE) 00000000 01aa0416 trace:mdi:DefMDIChildProcW current active 0x100a8, maximized (nil) trace:mdi:DefMDIChildProcA 0x100c0 0003 (WM_MOVE) 00000000 00430030 trace:mdi:MDIClientWndProc_common 0x20044 0210 (WM_PARENTNOTIFY) ff020001 000100c0
Вроде то же самое мигание и кривизна с окнами наблюдается в winefile.
да там эта проблема воспроизводится.
winefile и нагружать не надо просто через nx попробуйте запустить он раз по пять каждый список перерисовывает ;-((
Да, насколько я понял замечание в начале mdi.c, окно уже видимо в том\т момент, когда мы получаем извещение о том, что окно максимизировано. И тут уже поздно устранять мелькания. Короче, нужна схема событий и тесты. Особенно протестировать на NX.
Ждём принятия теста в cvs. Добавил патч, при котором окна по порядку переключаются так же как в винде, заметно ускорило переключение. Просьба протестировать.
Посмотрел. действительно стало побыстрее. теперь при переключении не все окна появляются на экране, а лишь одно, Главное меню мигает, как будто его перерисовывают для каждого одна.
Пока написанный тест, но не принятый в Hq показывает, что функция ShowWindow находится НА СВОЁМ месте в патче, но после сообщения WM_GETMINMAXINFO не отправляет сообщения WM_WINDOWPOSTCHANGED
Нашёл ошибки в тесте. Отправил новую версию в WineHQ
Меняю приоретет.
Это моя война.
Написал ещё один тест (приняли в Wine CVS), сейчас бьюсь над правильной работой ShowWindow, так как без правильной работы этой функции невозможно корректное переключение окон.
Можно ли описать, какими жестами 1С-MFC общается с mdi.c в Wine? Если проблему устранить невозможно, предлагается сделать хак по примерно следующей схеме: 1. Если MDI-окно максимизировано, и мы тыкаем в таб, чтобы переключиться на другое, взводим флаг 2. Перестаём перерисовывать окна до первой команды на максимизацию. 3. Снимаем флаг при получении команды на максимизацию. Таким образом, отрисовываться будет только максимизированное окно, один раз. Или все эти негативные метания окон происходят от обычного SendMessage(M_MDIACTIVATE ShowWindow(... SW_SHOWNORMAL) ?
(In reply to comment #17) > Можно ли описать, какими жестами 1С-MFC > общается с mdi.c в Wine? WINEDEBUG=+mdi > Если проблему устранить невозможно, Проблему устранить возможно, просто мне всегда не дают необходимого для этого времени. > предлагается сделать хак по примерно > следующей схеме: > 1. Если MDI-окно максимизировано, и мы тыкаем > в таб, чтобы переключиться на другое, > взводим флаг > 2. Перестаём перерисовывать окна до первой > команды на максимизацию. Ха-ха. > 3. Снимаем флаг при получении команды на > максимизацию. > Таким образом, отрисовываться будет только > максимизированное окно, один раз. Я могу ошибаться, но это надо переломать работу интерфейся по диагонали, т.к.: 1. Надо ловить такую штуку для MDI-окон и модальных окон во всех функциях, которые могут повлиять на положение и z-порядок окна. 2. Нужно лочить все перерисовки и сообщения о перерисовках 3. Этот хак будет отваливаться от любого чиха Джуллиарда на эту тему. 4. Это может сильно влиять на другие окна 1с и приложения. > > Или все эти негативные метания окон > происходят от обычного > SendMessage(M_MDIACTIVATE > ShowWindow(... SW_SHOWNORMAL) > ? > Можно посмотреть результаты user32crosstest по msg и больше не давать решения, немного не разобравшись в вопросе. P.S: Если такой хак кто-то сделает и быстрее чем я баги по фикшу и тесты выправлю, то я буду супер/мега/очень благодарен этому человеку. P.P.S: При условии, конечно, что он и будет эти грабли деражать..
Я считаю, что бага достаточно критична, т.к. все привыкли работать с терминалами, а wine+1c не дает должного результата, на unixforum.org сейчас идет обсуждение проблем. Локально и в файловом режиме, думаю мало кому это интересно, т.к. 1с по сети достаточно медленно. p.s. to etersoft: Можно ли повысить приоритет багам связанным с терм.режимом и nx? Думаю не один я в этом заинтересован.
Вы можете повышать приоритет (до P2 например), с соответствующим комментарием, почему это важно. Раз это критично для работы на терминальном сервере, повышаю приоритет.
Эту проблемы решил испрвлять капитально... Начал с просмотра тестов на ShowWindow и доделывания TODO.. Заметил, что SetFocus для скрытых окон странно себя ведёт, практически написал большой тест-кейс для последовательностей сообщений при вызове SetFocus на скрытые/нескрытые окна, работа в некоторых случаях существенно отличается от работы в Windows. Завтра доделую тест и отправлю в рассылку.
Тест отправил... жду ответов Джуллиарда, попутно выправил поведения для overlapped window при SW_HIDE (тест WmHideOverlappedSeq ).
Нашёл, что многие проблемы из-за неправильной реализации SetActiveWindow, написал для этой функции тесты, показывающие проблемы. Их приняли. Теперь выправляю поведения wine согласно тестам.
Хотел сначала выправить todo_wine { ok( ret == hwnd, "Failed to SetActiveWindow(hwnd), hwnd visible\n"); } как самый тривиальный, но оказалось, что возникают проблемы из-за неправильной работы предыдущего теста. В Windows после теста ret = SetActiveWindow(0); ok( ret == popup, "Failed to SetActiveWindow(0)\n"); ok_sequence(SetActiveWindowSeq0, "SetActiveWindow(0)", TRUE); Активное/фокус окно = hwnd, в wine же активное/фокус = 0, соответственно следующий тест проходит правильно, но возвращает неверный результат и из-за этого ломаются возвращаемые значения следующих тестов, поэтому возможный патч в WineHQ не примут. Буду править последовательность для первого теста...
Первая проблема - при SetActiveWindow(0) не выставляется хук - HCBT_ACTIVATE окну (точнее он пытаеся выставить его 0 окну), тесты под windows показываю, что для данного теста хук выставляется окну-родителю (hwnd), выставление хук всегда hwnd при 0 ломает кучу других тестов.
Вроде нашёл решение - если hwnd = 0, то присваиваем ему значение родителя активного окна. Такое решение улучшает ситуацию с тестами в msg. Сейчас обновлюсь до последних патчей, проверю ещё раз msg и win. И если всё ок - сформирую и отошлю патч.
Проверил на новых исходниках - всё ок. Сформировал патч и отослал в рассылку.
Пока отклика никакого. Сформировал ещё один патч по поводу сообщений палитрам ( WM_QUERYNEWPALETTE, WM_PALETTEISCHANGING), т.к. увидел, что в WIne эти сообщения нигде не обрабатываются, при прогонки тестов в Windows эти сообщения не отправляются. Вроде дополнительно ничего не падает. Спросил так же сообщество, знает ли кто-нибудь зачем в WIne так сделано.
Теперь пытаюсь правильно реализовать недостающий вызов SetWindowPos в SetActiveWindow. Сделал вариант: тесты msg - хорошо, win- валятся.
(In reply to comment #28) > Пока отклика никакого. Сформировал ещё > один патч по поводу сообщений палитрам ( > WM_QUERYNEWPALETTE, WM_PALETTEISCHANGING), т.к. увидел, что в WIne > эти сообщения нигде не обрабатываются, при > прогонки тестов в Windows эти сообщения не > отправляются. Вроде дополнительно ничего > не падает. Спросил так же сообщество, знает > ли кто-нибудь зачем в WIne так сделано. > Дмитрий Тимошков ответил: Try to run the tests in a paletted (256 color) mode. И действительно, если перевести Win98 в режим отображения 256 цветов - эти сообщения посылаются. Внёс их в тест на SetActiveWIndow и отправил в WineHQ
Сделал хак, который значительно ускоряет переключение между окнами ( думаю, что намного быстрее сделать уже вряд ли получится). Хак отправил в нашу рассылку. Багу закрываю, но вешать статус на неё "Закрыто" ещё рано - стоит привести переключение тому, как это сделано в Windows.
Стало существенно лучше. Но есть одно НО. Если выбираешь самый первый ТАБ, то все равно мерцание есть, а на всех осатльных нет. Получается что именно первый таб обрабатывается как то иначе... хотя странно. Если это можно исправить и сделать поведение первого ТАБа как и у всех других то будет хорошо...
(In reply to comment #32) > Стало существенно лучше. Но есть одно НО. > Если выбираешь самый первый ТАБ, то все > равно мерцание есть, а на всех осатльных > нет. Получается что именно первый таб > обрабатывается как то иначе... хотя странно. > Если это можно исправить и сделать > поведение первого ТАБа как и у всех других > то будет хорошо... > Нашли, что мерцание есть при переключении на окна, у которых в своей структуре есть две вкладки ( например: Диаграмма, Оборотно-сальдовая ведомость)
(In reply to comment #33) > Нашли, что мерцание есть при переключении > на окна, у которых в своей структуре есть > две вкладки ( например: Диаграмма, > Оборотно-сальдовая ведомость) > Похоже это из-за того, что такие окна делаются в виде составного окна из диалога и SysTabControl32 - это и вводит в заблуждение функцию переключения, которая выделяет эти окна как два отдельных и сначала позицирует первое, а затем второе - отсюда и мерцание.
Найдена ещё одна проблема: после переключения окон, при закрытии окна должно активироваться предыдущее активное, после моего хака это сломалось. Исправил это коммитом: Fix bug with last swithed window (found by Vika) f6070d0925aac48c0855fa961a349d0ba3bac045
Проверил, что проблема с миганием окон с двумя табами, не внесена моим хаком.
так как половина окон (форм) в 1С с табами, то предлагаю ошибку исследовать дальше.
(In reply to comment #36) > Проверил, что проблема с миганием окон с > двумя табами, не внесена моим хаком. > Естественно, сначала нужен хак, который исправит эту проблему. Потом следует дальше уделить этой ошибке внимание, - сделать переключение такое же как в Windows. Это необходимо потому, чтобы не возникало в дальнейшем проблем с изменениями в оригинальном wine, после которых хак перестаёт работать.
В таб-контроле позиция его, как окна, нигде не устанавливается. Отключить или заблокировать его нельзя, т.к. это выведет из строя ещё и панель переключения 1с (это один класс).
Решил всё-таки закоммитеть патч, т.к. по моему мнению становиться более шустрое переключение, да и тестам больше соответствует. Проблему с табами так и не решили. Заодно сделаю общий патч.
В заявке 7697 сообщается, что ошибка из комментария #35 не исправлена в сентябрьской сборке: в с сентябрьской сборке тот же баг с фокусом например: у нас есть окно с кнопками с которой можно окрыть журанл документов: 1) открыто окно с кнопками, давим на кнопку и открываем журнал документов 2) в журнале документов открываем любой документ 3) закрываем документ, фокус возвращается в ОКНО С КНОПКАМИ, хотя должен в журнал документов
(In reply to comment #41) > В заявке 7697 сообщается, что ошибка из > комментария #35 не исправлена в > сентябрьской сборке: > > в с сентябрьской сборке тот же баг с > фокусом > например: > у нас есть окно с кнопками с которой можно > окрыть журанл документов: > 1) открыто окно с кнопками, давим на кнопку и > открываем журнал документов > 2) в журнале документов открываем любой > документ > 3) закрываем документ, фокус возвращается в > ОКНО С КНОПКАМИ, хотя должен > в журнал документов > Это ни к этой баге, по-моему. Но в любом случае, уже я этим не занимаюсь.
Эта бага относится только к перерисовке окон. На возвращение к предыдущему окну заведена #2409. Нужно протестировать на последней сборке wine, с приложенными патчами Толи. Хорошо бы понять накакой стадии находится решение этой проблемы (то есть что перерисовывается лишний раз, а что нет). Бага #2409 проявляется независимо от этих патчей.
Бага очень критична для релиза. Андрей, проверь, пожалуйста, как можно скорее.
Проверил у себя на ноутбуке в Ubuntu 8.04 Описанной выше проблемы не выявил. Открывал в произвольном порядке окна, переключался между ними, закрывал. Проверил и в 7.7 и в 8.1
Бага переоткрыта для поиска более оптимального решения проблемы и доработки существующих патчей.
*** Bug 2720 has been marked as a duplicate of this bug. ***
Да и еще при переключении между распахнутыми окнами Меню отрисовывается несколько раз... В win такого незамечено...
Не успели добить :( Первоочередная задача к первому багфиксу.
(In reply to comment #48) > Да и еще при переключении между > распахнутыми окнами Меню отрисовывается > несколько раз... В win такого незамечено... > Да - эта проблема обостряется моими хаками (на эту багу).
Выложил патч. Надо протестировать, желательно с окнами, описанными в комментарии #33. Предлагаю на мигание меню завести отдельную багу, поскольку это не так критично как мигание окон.
Я думаю, что мерцание меню как раз к этой баге относится т.к. при перерисовке посылаются лишние сообшения для перерисовки меню...
Выложил дополнения к предыдущему патчу. Они должны решить проблемы мигания меню и лишюю перерисовку при переключении максимизированных окон мышью на панели окон.
Надо протестировать последний патч. Главное проверить, чтобы ничего c переключением окон не сломалось.
(In reply to comment #52) > Я думаю, что мерцание меню как раз к этой > баге относится т.к. при перерисовке > посылаются лишние сообшения для > перерисовки меню... > По-моему про мигание меню уже давно есть отдельная бага, что-то вроде "Меню в 1с перерисовывается два раза", на мне когда-то висела..
Сборка с патчами готова wine-1.0.9-alt33 wine-etersoft-sql-1.0.9-alt0.M40.11 libwine-1.0.9-alt33 Сейчас вроде все окна не перерисовываются и меню тоже 1 раз рисуется. Патчи вроде пока ниче не сломали. Надо компас посмотреть. Пока ошибку в FIXED.
Поставил последние обновления: libwine-1.0.9-eter34.1mdv.i586.rpm wine-1.0.9-eter34.1mdv.i586.rpm wine-etersoft-network-1.0.9-eter13mdv.i586.rpm* Окна также полностью перерисовываются и дергаются...
Еще раз посмотрел, не увидел полной перерисовки. И не дергаются. Какой у вас оконный менеджер?
(In reply to comment #58) > Еще раз посмотрел, не увидел полной > перерисовки. И не дергаются. > Какой у вас оконный менеджер? > Kde 3.5.10 (Mandriva 2008.1) Подклоючаются через X-терминал (XDMCP)
Мы знаем, что текущее решение ещё не идеально, будем постепенно улучшать. Это багу закрываю, просьба в неё больше не жаловаться. Конкретику про открывание окон будем выяснять в 2813.
*** Bug 2813 has been marked as a duplicate of this bug. ***
