Comments 35
Ой, этот комментарий был адресован вам.
Это не имеет какого либо отношения к многослойным окнам, и к тому же не позволит достичь того же результата, как в примере.
С кошкой хоть всё в порядке?
Боже, VB .NET, неужели его кто-то использует? Неудобно же писать код, просто борода!
Последний раз вживую работал с VB .NET года 3 назад при работе с DotNetNuke.
Так себе опыт :)
Последний раз вживую работал с VB .NET года 3 назад при работе с DotNetNuke.
Так себе опыт :)
А можно взять WPF и выставить там пару параметров.
Ну, WPF пока все же довольно тормозной, хотя на нем, конечно, такие вещи реализуются в разы проще…
Ну не скажите, WPF очень шустро отрисовывает даже сложные GUI.
Да ни разу не шустро. Запустил вот недавно чисто ради любопытства небольшую программку, к которой был применен порт темы Cosmopolitan c сервелата. Ничего сверхъестественного — таб контрол, тексбоксы, несколько кнопок — все контролы стилизованы, присутствует легкая анимация кое-где. Запустил на нетбуке с атомом N450. И были явные тормоза. Возможно, если ограничить FPS руками, будет быстрее, но все же, тормоза заметны. На среднем компьютере, возможно, будет менее заметно, но все же будет заметно.
WPF приложения требуют всяческих оптимизаций, чтобы работать сколь-либо пристойно. Работы тут для МС — непочатый край.
Я уж не говорю о времени старта приложения. Холодный старт просто очень долог, неприлично долог. Горячий тоже не особо, чтобы уж быстр.
WPF, как ни крути, в текущей редакции не годится для повседневных приложений, только если LOB…
WPF приложения требуют всяческих оптимизаций, чтобы работать сколь-либо пристойно. Работы тут для МС — непочатый край.
Я уж не говорю о времени старта приложения. Холодный старт просто очень долог, неприлично долог. Горячий тоже не особо, чтобы уж быстр.
WPF, как ни крути, в текущей редакции не годится для повседневных приложений, только если LOB…
У нас есть проект — приложение для финансового трейдинга, заказчик крупный международный банк. Требования к скорости работы приложения и отзывчивости интерфейса очень серьезные. Интерфейс приложения полностью сделан на WPF (.NET 4.0). Возможно ваши доводы основаны на опыте использования WPF более ранних версий, либо любительские приложения. В 4й версии майкрософт достаточно серьезно поработала над оптимизацией WPF.
Должно быть вы не используете анимацию. Без нее приложения работают относительно сносно. Но опять же, старт медленный и при таких обстоятельствах.
UFO just landed and posted this here
Анимации используются но, сугубо стандартного характера (подсветить кнопку при наведении, или, например, анимированный прогресс бар в заголовке таба)
Анимация, выходящая за рамки стандартного поведения стандартных элементов управления или идентичных им, в приложениях для корпоративного сектора как минимум неуместна. А избыточная анимация, которой так пестрят всевозможные демо WPF, в обычной жизни и вовсе будет дико раздражать.
Стандартные элементы управления — понятие достаточно расплывчатое. Если корпоративное приложение строго выдержано в едином стиле — стандартность элементов управления не имеет особого значения. Наличие анимаций — тоже не показатель низкого качества интерфейса. Все зависит от качества и уместности анимации в данном конкретном месте. Короче говоря, ваше суждение несколько шаблонно.
Да. Согласен. Главное — идентичность интерфейса во всем приложении. Но иногда нужно чтобы этот интерфейс не отличался от системного интерфейса самой ОС. Например когда компания разрабатывает собственную утилиту конфигурирования наподобие MMC. Я сам придерживаюсь следующего правила — если приложение можно отнести к «системным», то я стараюсь разрабатывать его, не применяя нестандартных элементов управления и схем оформления. А если какая-то задача не может быть решена при помощи стандартного элемента управления и мне нужно разработать какой-то специфический элемент управления — стараюсь комбинировать стандартные элементы управления для решения задачи. Например TreeListView (дерево с колонками) я делал через переопределение шаблона TreeView с использованием GridViewRowHeaderPresenter c переопределением схемы оформления для GridViewColumnHeader.
WPF использует DirectX для аппаратного ускорения отрисовки GUI. Если видеокарта — встроенная от Intel, то отзывчивости от интерфейса ожидать не стоит :(
В насыщенном UI, да еще и спроектированном неоптимально (лишние полупрозрачные градиенты и прочие ненадобности), очень плохо ускоряются. Особенно это относится к аппликейшенам типа упомянутого выше. Большое количество геометрии в темплейтах, анимации в пять десять слоев + куча биндингов, и в результате неимоверные тормоза. А если еще юзается либа типа Visifire, в которой для каждого вшивого элемента, для каждого датапоинта отдельный канвас используется, так вообще жесть. Трехмерку WPF пускает через DX, а вот двумерка не особо-то и ускорена (на личном опыте убедился — все печально).
Visual Studio 2010 на WPF написана, и ничего, хорошо работает.
Написан только UI. В фоне все тот же шелл. И работает через одно место, данное нам природой как раз для таких случаев. Ну мало-мальски сложных солюшенах и файловая система захлебывается от ее бэкэнда и UI тормозит неимоверно, когда на XAML не приведи Господь случайно наткнешься. Не дай Бог оставить включенным сплит-режим (разметка + дизайнер). 30 сек. (и более) открытие не слишком громоздкой разметки на Core i3 — это жесть. Почти минуту захлопывать сразу все вкладки (Close All через контекстное меню)… И тэдэ и тэпэ.
Я обожаю эту платформу, но тормоза выносят мозг…
Я обожаю эту платформу, но тормоза выносят мозг…
В WPF очень просто сделать ошибку по неосторожности, он гораздо сложнее, чем кажется. Писать под WPF надо крайне аккуратно. Нужно понимать, как будет обрабатываться лейаут, каков будет размер визуального дерева, как будут роутиться события, как будет работать виртуализация GUI, каков будет объём динамических и статических ресурсов.
По неосторожности можно запросто в разы увеличить объём потребляемой приложением памяти, например, если случайно разместить какие-нибудь тяжелые объекты в словаре ресурсов часто используемого элемента GUI (FrameworkElement.Resources), вместо словаря ресурсов сборки.
Виртуализация GUI отдельная сложная тема, позволяющая круто повысить производительность, за счет создания визуальных элементов на лету, по мере попадания их предполагаемого региона размещения в видимую область окна.
А еще есть кеш композиции, а еще… ну в общем вы поняли.
Иными словами — WPF в сегодняшнем виде — платформа для профессиональных разработчиков. Без большого объема знаний получить хорошую производительность при сложном GUI — сложная задача. Однако, если его освоить, то преимущества становятся очевидными. При желании, по производительности можно запросто переплюнуть Windows Forms. Но и недостатков, конечно, хватает.
По неосторожности можно запросто в разы увеличить объём потребляемой приложением памяти, например, если случайно разместить какие-нибудь тяжелые объекты в словаре ресурсов часто используемого элемента GUI (FrameworkElement.Resources), вместо словаря ресурсов сборки.
Виртуализация GUI отдельная сложная тема, позволяющая круто повысить производительность, за счет создания визуальных элементов на лету, по мере попадания их предполагаемого региона размещения в видимую область окна.
А еще есть кеш композиции, а еще… ну в общем вы поняли.
Иными словами — WPF в сегодняшнем виде — платформа для профессиональных разработчиков. Без большого объема знаний получить хорошую производительность при сложном GUI — сложная задача. Однако, если его освоить, то преимущества становятся очевидными. При желании, по производительности можно запросто переплюнуть Windows Forms. Но и недостатков, конечно, хватает.
Да, с этим совершенно согласен. Microsoft надо оптимизировать это так, чтобы высокая производительность была доступна без танцев с бубном. Большинство начинающих программистов таких тонкостей не знают, потому большинство приложений выйдет медленными. Даже разработчики Evernote, далеко наверно не бездари, не смогли добиться достаточной производительности. Разработчики Lenovo с их набором софта для Think Pad. Intel с панелью управления графическим адаптером и т.д. и т.п. Куда уж тогда менее опытным программистам.
> Виртуализация GUI отдельная сложная тема, позволяющая круто повысить производительность
… или огрести багов по скроллингу. WPF Toolkit + Virtualization + ScrollBar (особенно навешенный в темплейте + участие биндингов) == Куча Трудноустранимых багов.
> Microsoft надо оптимизировать это…
Причем тут M$? Учим матчасть… все есть — просто надо знать лучшие практики, а не видики с индусами зырить и не говнокод копипастить.
… или огрести багов по скроллингу. WPF Toolkit + Virtualization + ScrollBar (особенно навешенный в темплейте + участие биндингов) == Куча Трудноустранимых багов.
> Microsoft надо оптимизировать это…
Причем тут M$? Учим матчасть… все есть — просто надо знать лучшие практики, а не видики с индусами зырить и не говнокод копипастить.
>… или огрести багов по скроллингу.
А не надо лезть напрямую в визуальное дерево из кода модели. Опасность виртуализации в том, что нельзя быть уверенным в том, что для элемента модели на какой-то момент времени существует визуальный контейнер. Этот факт по неопытности может принести много неприятностей. Самый простой пример — есть иерархическая объектная модель, которая визуально представляется в виде дерева. Задача — развернуть дерево так, что бы был виден определенный узел. Если попытаться влезть в визуальное дерево контрола дерева, то получим жесткий облом, т.к. ItemsControl.GetContainerForItem может ничего не вернуть! Выход из подобных ситуаций — спуск нужной логики во ViewModel. Для дерева в объект модели, соответствующий узлу добавляем свойство IsExpanded, делаем к нему Binding из шаблона узла, и всё! Развернутостью узлов можно управлять при обращении к модели. На то в общем то ViewModel и отделен от Model. Речь, само собой, про паттерн MVVM, самый популярный для WPF, в той или иной форме.
На счет скроллинга — ScrollBar должен корректно работать если его целевая панель корректно реализует IScrollInfo. Если что-то работает не так, то это вина разработчика класса панели.
WPF Toolkit вообще штука сырая, полно багов. Долго плевался от тамошнего DataGrid'а. После доработки напильником и пары хаков через рефлексию пашет более-менее сносно.
К слову, лично засабмитил несколько багов по WPF на Microsoft Connect. Году эдак в 2009м. Так они в активе и висят… Так что проще по ходу делать хаки, благо, что исходники есть.
А не надо лезть напрямую в визуальное дерево из кода модели. Опасность виртуализации в том, что нельзя быть уверенным в том, что для элемента модели на какой-то момент времени существует визуальный контейнер. Этот факт по неопытности может принести много неприятностей. Самый простой пример — есть иерархическая объектная модель, которая визуально представляется в виде дерева. Задача — развернуть дерево так, что бы был виден определенный узел. Если попытаться влезть в визуальное дерево контрола дерева, то получим жесткий облом, т.к. ItemsControl.GetContainerForItem может ничего не вернуть! Выход из подобных ситуаций — спуск нужной логики во ViewModel. Для дерева в объект модели, соответствующий узлу добавляем свойство IsExpanded, делаем к нему Binding из шаблона узла, и всё! Развернутостью узлов можно управлять при обращении к модели. На то в общем то ViewModel и отделен от Model. Речь, само собой, про паттерн MVVM, самый популярный для WPF, в той или иной форме.
На счет скроллинга — ScrollBar должен корректно работать если его целевая панель корректно реализует IScrollInfo. Если что-то работает не так, то это вина разработчика класса панели.
WPF Toolkit вообще штука сырая, полно багов. Долго плевался от тамошнего DataGrid'а. После доработки напильником и пары хаков через рефлексию пашет более-менее сносно.
К слову, лично засабмитил несколько багов по WPF на Microsoft Connect. Году эдак в 2009м. Так они в активе и висят… Так что проще по ходу делать хаки, благо, что исходники есть.
Это все понятно… для виртуализованного элемента вне вьюпорта нет контейнера. Я о другом писал. Возникают проблемы с контекстным меню на скроллбаре, который определен в шаблоне контрола. Вот навешен в шаблоне на скроллвьюер внешний скроллер и получает он (скроллер) неправильный размер ползунка (например, меньше, чем должно быть), а в результате команда «Bottom» в контекстном меню двигает нутро скроллвьюера слишком далеко вверх. Пол дерева в TreeView как не бывало.
Ничего не понял, что у вас, ScrollBar, ScrollViewer, или какой-то свой скроллер. И при чем тут размер ползунка? У ScrollViewer'а есть вьюпорт, его размеры и положение. Работать с прокруткой через размер ползунка у ScrollBar'а относительно его общего размера, это мягко говоря, не корректно. Но как-то неправильно у вас команда реализована по моему. Она что ли явно устанавливает свойство ScrollViewer.VerticalOffset? Если нужно что-то прокрутить, то надо либо юзать методы ScrollViewer'а, а у него есть метод ScrollToBottom, либо нужно обращаться к IScrollInfo панели, которая хостит элементы.
Есть шаблон для WPF Toolkit DataGrid, в котором определены вьюпорт и скроллбар. Положение содержимого скроллвьюера завязано на скроллбар, у которого имеется свое собственное (нативное) контекстное меню. В этом контекстном меню есть команды, перемещающие ползунок.
У DataGrid включена виртуализация, т.е. контейнеры созданы только для видимых итемов. Теперь вопрос: как скроллвьюер определяет суммарную высоту своего контента, если не все элементы DataGrid реально отрисованы и как определить точные параметры для скроллбара?
Надо будет на досуге покопаться, когда время на это будет.
У DataGrid включена виртуализация, т.е. контейнеры созданы только для видимых итемов. Теперь вопрос: как скроллвьюер определяет суммарную высоту своего контента, если не все элементы DataGrid реально отрисованы и как определить точные параметры для скроллбара?
Надо будет на досуге покопаться, когда время на это будет.
У WPF все еще холодный старт порядка 4 секунд, и текст все еще не отрисовывается так же, как на WPF (непонятно зачем Direct2D/DirectWrite делали).
Да, на WPF это реализуется проще, согласен, но не все любят и хотят работать с WPF. Да, и описаный способ можно использовать в нативных приложениях, а WPF это только .NET.
Вот я тоже начал читать и сразу мысль возникла: а причем тут, собственно, .Net? Статья об использовании WinAPI. Хотел даже минуснуть статью, т.к. описание не очень хорошей практики скрытия оконно обвязки и рисование «фердипердозных» окошек в WPF — тема избитая, или даже нубская, вобщем на мойвзгляд не для хабра.
Судя по фото топика, жена автора уже задолбала
Sign up to leave a comment.
Окна «неправильной» формы