У вас подчеркнуто волнистой линией в xaml коде
Значит либо в базовой верстке ошибка, либо не подключили нужны using в коде (или те что xmlns:...)
PS/ и не используйте allowtransparency =true
просто замерьте производительность с этой опцией и без нее.
Эта настройка убъет вам все анимации (в т.ч. и банальные выезжания менюшек и попапов (у них будет полтора FPS вместо 60)
Понаделают нестандартных окон кривыми способами, а потом все ругаются что WPF приложения тормозят)))
Для всяких нестандартных окон используйте chrome window https://docs.microsoft.com/ru-ru/dotnet/api/system...
Мой рабочий компьютер раз в 10 слабее вашего, тоже амд, и я занимаюсь дизайном WPF приложений, - ничего не лагает.
Скорее всего кривая верстка форм с глубокой вложенностью, кривое приложение, (т.к. вы двигаете элементы мышкой там, то 99% это кривая верстка)
или неверное использование designView моделей. (возможно тянете в дизайн код огромные списки, которые естественно там не виртуализируются или вроде того)
Если в пустом проекте тоже лаги, значит что-то со студией уже.
Но вообще рекомендую не использовать визуальный редактор студии. Вообще отключить его, т.к. он часто врет. Удобнее в реал-тайме запустить проект и править код верстки, сразу видя изменения в реальном приложении. Выставлять мышкой элементы в форме WPF - это кощунство, убъете миллионом кривых отступов всю изящность XAML кода.
twoone
Как хорошо, что новое поколение не хочет годами работать на портфолио и читать книги профессионалов.
Это лишь означает, что в мои 35 чем меньше они знают и умеют, тем более ценен я как специалист, даже если буду работать левой пяткой.)
Забей, зачем вообще нужен конструктор, если сейчас в рантайме разметку XAML можно менять, что надежнее и точнее?
в 2010м конструктор в студии вообще не работал))
Если совсем приперло - юзай конструктор Microsoft Blend for VS, тот отображает все всегда как надо.
Разработали пару десятков киосков и аппов для встраиваемых систем включая умные дома.
Везде куча интерактива анимации и пр..
Там есть все инструменты для создания сколь угодно сложной графики.
Собственно UWP /WPF изначально созданы для интерактива ЧЯДНТ ? )))
Просто изучите XAML верстку, построение стилей и анимации более глубоко.
UWP в плане визуализации лучше, т.к. на пару порядков более производителен в GUI чем WPF.
Эх...
То что вы показали, и то что вам посоветовали в ответе это просто картинки без базы за спиной.
Ищите скриншоты реальных UI, лучше видео.
Как правило ни один из дизайнеров что вот такое показушное рисует не способен реализовать UI рельной SaaS или CRM, по опыту мы максимум что оставляем от такого вот говна в релизе это цветовую гамму, чаще просто объясняем заказчику, что наняв такого дизайнера он просто потратил деньги на ветер и переделываем заново.
Беда кроется в отсутствии опыта реализовывать на практике нарисованное, нарисовал - деньгу получил - слился. Таков жизненный цикл этих пестреньких картинок.
Но да, плюсиков в карму и сотен тысяч просмотров без таких работ в портфолио где-нибудь на дриббле - не заработать.
Дизайн ради дизайна, но все забыли о пользователях. Артём Петренков правильно подсказывает, UI подобных систем должен начинается с решения конкретной задачи, если задача будет успешно решена, тогда уже можно подумать о красоте.
Кроме того дизайн должен еще и под конкретную платформу разрабатываться, нарисовать можно что угодно, кто это потом реализовывать будет и на каких технологиях/ элементах. Этот вопрос должен быть решен до дизайна.
Просто с ходу без конкретной задачи и и юзер-кейсов ваши работы будут не более чем бутафория и кроме как практики рисования кнопочек в вакууме вы ничего не получите.
Foggy Finder, маленькое дополнение, в данном решении есть проблемка: чем больше будет контента в окне и чем больше разрешение, тем больше будет тормозов на анимаци.
Ход решения верный, но контент анимации надо хранить не как Object, а как Bitmap.
В итоге должны анимироваться 2 картинки, что позволит анимировать плавно контент любой сложности даже на 4k мониторе. Сохранить контент как картинку можно стандартными функциями WPF.
rmkk, о, благодарю.
Надо будет как-нибудь поисследовать поглубже с чем это связано.
возможно с тем, что на мобилках данные списки будут открываться иначе, нежели в десктоп браузерах, а т.к. мобильного трафика сейчас в целом больше, хотя гугл тоже те еще затейники в плане дизайна, возможно - просто так захотелось.
BD_ l3ftoverZ! Счастья, здоровья (тем кого не останавливает), сухарей побольше.
Одно дело для себя так делать (свой сайт) и совсем другое - под заказ.
Страйк от ваканима (а им вроде лицензия на наруто в РФ принадлежит) и веселая житуха обеспечена.
Хм..
PRISM скорее как раз наоборот для больших и серьезных проектов, слишком перегружен, модульная архитектура и все такое.
Для простенького есть MVVM Light, говорят.
Мы как-то в итоге пришли к своей упрощенной архитектуре, на основе басиса призмы, просто взяли только то, что надо нам и в зависимости от проекта, делаем уникальную архитектуру остальное выбросив.
Фреймворк и технологии должны выбираться под проект, а не наоборот, иначе так и будете по граблям ходить.
Adamos, каждый GUI фреймворк имеет право на жизнь.
Вопрос тут не дизайна а задачи.
На QT/WPF/electron и т.п - писать бизнес приложения самое то.
На юнити - игрульки это первостепенно он для них и позиционируется.
Но, предположим, завтра к вам приходит заказ: разработать визуализацию генома человека
представить наглядно все 20 тыщ генов с зумом до молекул.
Unity и Unreal (в зависимости от того C# или C++) будет мой выбор, хотя я и приверженец старой школы.
Просто потому что эта задача им по силам уже на уровне бизнес-логики практически из коробки. А графическая часть вообще вне конкуренции.
Затраты времени и качество итогового продукта никак не сравнимы с выбором "нормальных" библиотек в данном случае.
Adamos, на всякий случай уточню, на максимум это не значит "загружать ресурсы на 100%" )))
Как раз наоборот при минимальных затратах - максимальную производительность отдавать.
К сожалению, современные GUI фреймворки далеко не все такие. Взять например новомодный Electron с его прожорливостью в оперативной памяти (=> нагрузка на процессор и просадка батареи). Или старый добрый WPF у которого весь GUI запихнут в 1 поток, кеширования нет вообще (хотя можно своё написать) и анимации висят на процессоре. Да, при достаточных скилах это можно обходить, + в последних фреймворках правят потихоньку недочеты, но в руках новичков даже простенькое ПО становится тормозным из-за платформы которая не была оптимизированна изначально. Но если сравнивать их со старичками то они на порядки лучше конечно же.
Foggy Finder
Я тоже мыслю в разрезе что в MVVM слой View это view.xaml+view.cs
т.к. XAML можно формировать кодом, как и всяческие биндинги, анимации и пр.
Например у нас была задача именно кодогенерации XAML из xml шаблонов, можно конечно извращаться и пихать описание визуала в ViewModel, или вынести все в какой-нибудь UserControl, но нет.
Так или иначе любой XAML код содержит в себе c# код на уровне контрола, почему же вся Page не может содержать в себе такой код? вы же привязываете дата контекст там, хотя это можно сделать и в XAML)
Понятное дело то, что можно сделать по канонам MVVM лучше сделать привычно)
Представление патерна как (view.xaml+view.cs) + (view model) + (model) избавляет от многих ошибок и лишнего кода, по факту ничего не нарушая если этот код не работает с данными модели.
Кстати ребята из гугла у Flutter это как фичу подают )
PS/ и не используйте allowtransparency =true
просто замерьте производительность с этой опцией и без нее.
Эта настройка убъет вам все анимации (в т.ч. и банальные выезжания менюшек и попапов (у них будет полтора FPS вместо 60)
Понаделают нестандартных окон кривыми способами, а потом все ругаются что WPF приложения тормозят)))
Для всяких нестандартных окон используйте chrome window
https://docs.microsoft.com/ru-ru/dotnet/api/system...