.NET: проблемы с перерисовкой окон
скорее всего, все-таки не очень стандартные контролы
Нет-нет, в одном из проектов вообще висят только кнопки, лейблы и эдит-боксы.
Можно ли поймать события от других приложений о том, что над моим окном перемещаются другие?
Можно ли поймать события от других приложений о том, что над моим окном перемещаются другие?
А двойная буферизация не помогает? (см. свойства формы)
Вот тут пример этого артефакта:Программа в это время занимается какой-либо деятельностью?
Если взять стандартное окно класса Form, .NET 2.0Стандартные окна .net-а так себя не ведут.
...
Есть ли у кого-нибудь рецепт, как с этим бороться?
Согласен с -ом, что такое только может быть - если засирается gui-поток.
Gui-поток можно засрать - или долгим выполнением Paint-а, или долгой работой в windows forms timer-е
или в Control.Invoke
В том то и дело, что нет, все остальное вынесено в отдельные
потоки BackgroundWorker ом.
Ради эксперимента создал пустую форму, напихал туда контролов,
и вот что получилось:
http://www.ljplus.ru/img4/b/o/boshetunmaj/Redraw2.jpg
Исходники тут:
http://ifolder.ru/5710966
потоки BackgroundWorker ом.
Ради эксперимента создал пустую форму, напихал туда контролов,
и вот что получилось:
http://www.ljplus.ru/img4/b/o/boshetunmaj/Redraw2.jpg
Исходники тут:
http://ifolder.ru/5710966
Железо какое?
я вот всё думаю: неужели у всех остальных такого не наблюдается?
VS 2005, если что..
P4 3200, 2 гб RAM, geforce 5200.
VS 2005, если что..
P4 3200, 2 гб RAM, geforce 5200.
неужели у всех остальных такого не наблюдается?У меня все ок.
хм, может какие настройки студии?
а ОСь какая стоит?
а ОСь какая стоит?
хм, может какие настройки студии?Я запустил тобой откомпелированный ехешник.
а ОСь какая стоит?
XPSP2
У меня все ок. Windows Vista, запускал .exe файл, который был в архиве
Кстати, у тебя видюха какая?
GeForce 5200.
На рабочем компьютере те же баги видны...
На рабочем компьютере те же баги видны...
Ты точно запускаешь ту прогу, что нам дал? И вообще, мерцание появляется сразу после запуска или надо сначала на какие-нибудь кнопочки понажимать?
небось надо понажимать, создаётся десяток рабочих потоков и на отрисовку гуйни просто процессорного времени не хватает
Вот мне тоже так кажется.
да, WindowsApplication1.exe 
Сразу возникает, водить окошком надо активно... Может у вас не так оно заметно, но если, для сравнения, поводить тем же калькулятором на другим приложением - Оперой, например - небо и земля.
Сразу возникает, водить окошком надо активно... Может у вас не так оно заметно, но если, для сравнения, поводить тем же калькулятором на другим приложением - Оперой, например - небо и земля.
если всё засирает рабочий поток, то у кого двух (и более)-ядерный проц, ничего заметно не будет
На нажатие кнопок ничего не навешано!
Кстати, если форма вообще пустая, без контролов - то такого эффекта нет. Какие-то проблемы с обновлением контролов...
Кстати, если форма вообще пустая, без контролов - то такого эффекта нет. Какие-то проблемы с обновлением контролов...
кстати да - от одного движения окошка калькулятора над моим процессор засирается на 80%. Вопрос - почему так получается?
Поставь драйвер видеокарты.
причём, самой последней версии
Жестоко. А здесь, как раз, некоторые личности настаивают, что производительности современных машин достаточно, чтобы юзать .нет и c# в качестве основного языка разработки. Отчасти они правы, ибо переход на многоядерный процессор, действительно, снимет проблему. Но, всё же, что то здесь не так.
А вообще странно. У меня на gtk# таких багов при проведении окном над примерно так же утыканном виджетами окошком нет, хотя, насколько я знаю, gtk уровнем сильно выше чем windows.forms (поправьте, если не так а машинка у меня послабее.
кстати да - от одного движения окошка калькулятора над моим процессор засирается на 80%.скорее всего это связано с тем, что .net-программы по умолчанию включают поддержку визуальных стилей, и скорее всего именно эта отрисовка и тормозит.
А вообще странно.Да, странно. Потому что проблема только на твоих компьютерах. Ни у кого больше её нет. Значит, либо ты делаешь что-то не так, либо все остальные...
Отчасти они правы, ибо переход на многоядерный процессор, действительно, снимет проблему. Но, всё же, что то здесь не так.кстати, WPF с большим кол-вом контролов, быстрее отрисовывается, чем winforms-приложение с таким же большим кол-вом контролов
Да, странно. Потому что проблема только на твоих компьютерах.? У меня с ГТК в линуксе с тормозным в 2d проприетарным драйвером нвидии нет такой проблемы, в венде бы всё вообще летало.
? У меня с ГТК в линуксе с тормозным в 2d проприетарным драйвером нвидии нет такой проблемы, в венде бы всё вообще летало.Это не имеет никакого отношения к проблеме с Windows Forms.
ты не окосел? со зрением всё нормально? я не топик стартер, если что 
Ну как пишешь, такие и ответы получаешь. 
можно ли это отключить?
Тут еще что наблюдается: если я в отдельном потоке создаю еще одно окно, от него ловлю
событие Move и при этом событии в основном окне делаю DoEvents - всё выглядит куда как приятнее и загруз процессора не такой большой. Это значит, что можно обойтись внутренними средствами, не прибегая к таким нереальным методам, как установка новых драйверов или двухядерного проца.
Отсюда, Внимание, вопрос: как ловить такое же событие от окон сторонних приложений?
Тут еще что наблюдается: если я в отдельном потоке создаю еще одно окно, от него ловлю
событие Move и при этом событии в основном окне делаю DoEvents - всё выглядит куда как приятнее и загруз процессора не такой большой. Это значит, что можно обойтись внутренними средствами, не прибегая к таким нереальным методам, как установка новых драйверов или двухядерного проца.
Отсюда, Внимание, вопрос: как ловить такое же событие от окон сторонних приложений?
если я в отдельном потоке создаю еще одно окно,так делать нельзя. Почитай любую книгу по Windows программированию, или даже просто по Windows Forms. Это может привести к очень неприятным эффектам, вплоть до зависания приложения.
не прибегая к таким нереальным методам, как установка новых драйверов или двухядерного проца.Оё. Чувак, объясняю медленно, как для милиционера: у тебя что-то не то с компом, драйвер для видеокарты не установлен, или установлен старый глючной, или вирус какой, или антивирус. Дотнет тут ни при чём. Тебе нужно решать проблему со своим компом, а не извращаться с дотнетом.
Объясняю для тех кто в танке: с железом у меня всё в порядке, все не .NET приложения работают отлично: в том числе написанные на MFC.
Думаете, это профессионально - советовать конечному пользователю вместе с приложением купить себе двухядерный проц, топовую видеокарту и т.п.?
Думаете, это профессионально - советовать конечному пользователю вместе с приложением купить себе двухядерный проц, топовую видеокарту и т.п.?
если groupbox-ы убрать, проблема остается?
Верная мысль! Без них проблемы практически нет!
а в чём проблема groupbox-ов?
у них там какой-то мега сложный код отрисовки
Двойная буферизация групбоксов слегка помогает,
но в целом все равно проблема остается. Похоже, проще сделать свой контрол,
который будет отрисовывать чисто рамку и всё.
но в целом все равно проблема остается. Похоже, проще сделать свой контрол,
который будет отрисовывать чисто рамку и всё.
Конечный клиент кто? Ты?
В этом треде было несколько типа конечных клиентов, ну как бы, и ни у одного из них никаких проблем не было. Включая меня, например. Даже на 98ой винде в виртуальной машине.
Не, я всё понимаю, но дичайше тупо выглядит. А если у "конечного клиента" окажется битая память и дотнетовская прога, любящая отожрать как можно больше до первой сборки мусора, будет падать, тоже попросишь совета насчёт того, как бы грязно отхачить GC, чтобы такого не было?
В этом треде было несколько типа конечных клиентов, ну как бы, и ни у одного из них никаких проблем не было. Включая меня, например. Даже на 98ой винде в виртуальной машине.
Не, я всё понимаю, но дичайше тупо выглядит. А если у "конечного клиента" окажется битая память и дотнетовская прога, любящая отожрать как можно больше до первой сборки мусора, будет падать, тоже попросишь совета насчёт того, как бы грязно отхачить GC, чтобы такого не было?
Ты как-то неправильно мыслишь. из того, что артефакты появляются при отрисовке групбоксов, вовсе не селдует, что их отрисовка глючит не из-за драйверов с ошибками.
Впрочем, Microsoft выложила исходники .NET'а, можешь в принципе эти GB отдебагать, если уверен в драйвере.
Впрочем, Microsoft выложила исходники .NET'а, можешь в принципе эти GB отдебагать, если уверен в драйвере.
Лично запускал свою прогу на .нет 2.0 на трёхсотом пне с девяносто восьмой виндой, никаких глюков с прорисовкой не было, что за хуйню ты вообще несёшь про двухъядерные процы?так запускал просто прогу на .net? или прогу на .net с groupbox-ами?
проверять желательно на desktop-е с высоким разрешением при нескольких открытых тяжелых gui-ишных приложениях.
в таких условиях контролы внутри groupbox-ов действительно довольно серьезно начинают артифачить.
это вызвано тем, что у большинства .net-ных контролов явно выставлена отдельная заливка background-а, а у groupbox-а еще и сам по себе навороченный код отрисовки.
У него вроде виста... Там такого глюка при включеном Aero быть не может...
Хотя он его выключает, вероятно
Хотя он его выключает, вероятно
Оставить комментарий
odissey
Если взять стандартное окно класса Form, .NET 2.0, то имеем следующий артефакт: когда над этим окном пользователь водит окном другого приложения, то перерисовка окна .NET происходит очень похабным образом (остаются следы от окна другого приложения и т.п. даже если в окошко понапиханы довольно стандартные контролы.Есть ли у кого-нибудь рецепт, как с этим бороться?