Summary: | 1Cv77: Медленная прорисовка меню | ||
---|---|---|---|
Product: | WINE@Etersoft | Reporter: | Александр Пликус <pav> |
Component: | Окна / фокус / перерисовка | Assignee: | BUGS@Etersoft <bugs> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P4 | CC: | baraka, fe, igor, kondratyuk, lav, shpigor |
Version: | 1.0.8 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | |||
Заявки RT: | Связано с: | ||
Дата напоминания: | |||
Bug Depends on: | 1840, 3971 | ||
Bug Blocks: | 760, 3174, 8500 | ||
Attachments: |
лог по WINEDEBUG=+event
Скриншот |
Description
Александр Пликус
2007-12-18 12:52:41 MSK
на локальной dbf базе тоже самое на 27 релизе с пустой локально раположенной базой тоже медленно. Хотя рабочая заполненная база работает нормально. Отличие только в .wine. Оказалось, что медленно откравыются пункты меню с картинками Толя, надо посмотреть почему в 1С так странно (по два раза) меню отрисовывается. Быть может есть причина. При проверке на CentOS/5 (GNOME) обнаружилось, что меню не перерисовывается дважды, и быстро открывается. Проверял на Gnome под Alt Linux 4.0 - точно так же всё тормозит, как и в KDE. В wwo такие же проблемы. Заметил разницу, что в CentOS/5, где идеально работает меню, при заполнении его создаются картинки : 11drv:X11DRV_CreateBitmap (0x3a84) 8x8 24 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x3a84, buffer=0x11c5a88, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x3a90) 22x20 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x3a94) 20x20 1 bpp а у нас в Альте с KDE, создаются с 16 bpp Проверил на cellar локально, если поставить в настройках Xorg 24 bpp, то на Nvidia под KDE в AltLinux 4.0 всё отрисовывается быстро. Ещё забыл добавить, что на CentOS/5 меню тоже два раза отрисовывается (судя по трейсам) и действия одинаковы при медленной отрисовке и быстрой. Считаю, что при использовании 16 bpp по неясной причине слишком долго создаются картинки иксовыми функциями, из-за этого такие тормаза при отрисовке меню. У Саши выставили 24 bpp, картинки, судя по трейсам, с 24 bpp создаются, но всё тормозит. Есть предположение, что это из-за того, что видеокарточка radeon (как и у меня) При локальной работе меню у Саши рисуется тоже быстро. Выставили 16 bpp Саше, запускали локально. Меню перерисовывается быстро. Не занимаюсь. Не занимаюсь. Выложил патч. По сути это хак, запрещающий отрисовку по событию Expose для окон стиля (WS_POPUP | WS_CLIPSIBLINGS | WS_VISIBLE). Поскольку, у таких окон нет border или thickfarme, скорее всего, хак затронет только вспомогательные popup окна, пропадающие при потере фокуса. Немного потестировал в Компасе, 1с8, Налогоплательщике, FineReader. Проблем вызванных этим патчем не обнаружил. Всё же будь готов вставить проверку на 1С, если обнаружится, что что-нибудь ломается совсем стороннее. Или может быть стоит сделать сразу? Выложил TRY 2 с проверкой на версию 1с7. /*Протестировано*\ http://rt.etersoft.ru/Ticket/Display.html?id=9277 Ошибка вернулась. 1с 7.7 eter37/eter15 mandriva 2008.1 Происходит при работе клиента по сети, то есть на сервере запускается процесс и его вывод направляется на X-сервер клиента. В случае локального запуска всё работает нормально. При работе по сети медленно и по два раза перерисовываются меню. Created attachment 997 [details]
лог по WINEDEBUG=+event
Created attachment 998 [details]
Скриншот
Похоже здесь 2 проблемы (о которых говориться в заявке): 1) Не пропадает предыдущее окно меню, пока новое до конца не отрисуется 2) Пункты меню отрисовываются медленно Можно как-нибудь у нас протестировать, что меню прорисовывается 2 раза? Локально отрисовка происходит только 1 раз. > 1) Не пропадает предыдущее окно меню, пока
> новое до конца не отрисуется
Эта проблема связана с тем, что для отрисовки пункта меню вызывается MENU_DrawMenuItem, которая для элементов с MF_OWNERDRAW посылает WM_DRAWITEM родителю.
Некоторые пункты меню содержат только текст и родитель отрисовывает их также быстро, как в windows. Если же пункт меню с картинкой, то родителем вызывается BitBlt, которая работает достаточно медленно. Пока родитель не отрисует все, MENU_DrawMenuItem не вернет управление, а 1с сначала рисует открываемое окно меню, а потом стирает предыдущее.
Реализация dib engine должна решить багу.
Нет исполнителя bugs@, решать некому пока. Решили отложить. Жалоб нет, DBI Engine есть. Закрываю. |