WPF UWP XAML forever
Делаю софт и пользовательские интерфейсы
Контакты

Достижения

Все достижения (2)

Наибольший вклад в теги

Все теги (17)

Лучшие ответы пользователя

Все ответы (38)
  • GUI для C++. Как можно?

    cyber_roach
    @cyber_roach
    XAML UX дизайнер INEDIapps
    Под какую платформу?
    Это собственно главный вопрос. Выбор языка сегодня вторичен.
    Кроссплатформенность сегодня это миф, так или иначе вы будете либо идти на компромиссы (часто жестко), или мучатся с каждой ОС по отдельности по факту используя пару десятков общих классов которые вам и в обычном (не кроссплатформенном режиме) никто не мешает собрать под все платформы в отдельный ресурс с той же скоростью.
    Выбор платформы
    * Если windows ничего не мешает использовать UWP / WPF
    * MFC -вы серьезно хотите писать ПО на библиотеках 92го года? да они поддерживаются, но новое что-то писать на этом разве что ради фана, либо что-то специфичное под старые win системы.
    * CEF - не сталкивался, но думаю мало что хорошего в идее использовать браузерный GUI и плюсы. (если не для браузера пишите)
    * QT, сложный вопрос, есть его ярые поклонники не признающие ничего кроме, но я к нему нейтрален, считаю его устаревшим, хотя для встравиваемых систем и под линукс - да, т.к. практически нет альтернатив часто. Под эти платформы я бы выбрал qt только потому что на нее много информации в интернетах и сообщество имеется.
    * под мобильные платформы... все довольно сложно, решений вроде как есть, но я бы сегодня использовал для GUI что-то другое(Например Flutter), а c++ для отдельных модулей ибо - замучаетесь отлаживать.
    * Если GUI хочется сложный и необычный/игровой да еще и кроссплатформенно Я бы использовал необычное сочетание UnrealEngine + NoesisGUI, где Unreal решит все проблемы с платформами и производительностью Noesis с разметкой UI. Но придется пожертвовать почти всеми системными функциями на каждый чих делая кастомное решение.

    Важные моменты
    - Графическая библиотека должна использовать железо на максимум.
    т.е. без апаратного ускорения и отрисовкой видеокартой можно выбрасывать все ваши красивости на помойку.
    Наверное часто замечали что над GUI постарались, но забыли про производительность.
    Если под win попробуйте UWP, он супершустр, если честно быстрее и качественнее него в отрисовке GUI ничего не встречал. Съедает любую сложность GUI при верном подходе для любого устройства ввода-вывода (клавитура/мышь, тач на 20 касаний, сенсорные перья, VR…) Какой-нибудь QT возможности даже и не снятся, хотя вторая много старше.
    К сожалению платформа не популярна. Есть небольшая, но вероятность, что сдохнет, т.к. windows маркет не развился. Хотя недавно добавили возможность писать ПО и для обычного десктопа минуя распространение через магазин, но пока все сырое. ну и так же MS выкладывает все потихоньку в openSource это радует.
    Хотите стабильности от жизни - берите QT, лет 10 еще точно актуальна будет. Хотите простоты и скорости разработки, UI посовременнее и посложнее - что-то из нового.

    - Второй момент, после производительности. Графическая библиотека сегодня - это совместимость с "современным дизайном" .
    Что я имею ввиду: когда дизайнер вам дает исходник в Figma/Sketch, иконки в SVG видео в h264 и пр. и вам нужно рассмотреть использование этого всего на устройствах 96-300 dpi где все будет адаптивно и подстраиватся под размеры и ориентацию экрана. Вы не должны испытывать боль заднего прохода. Берете и делаете, т.к. у вас есть для этого инструменты.
    Наверное видели супермелкоту в windows программах когда DPI экрана под 300, это как раз MFC, QT и подобные
    Про линукс на FullHD планшете 8" это отдельная большая тема беседы. Хотя вроде как в последних сборках имеется поддержка hiDPI устройств.
    Тоже самое под мобильные платформы. из-за разнородицы dpi я как раз и рекомендовал использовать что-то вроде Flutter, т.к. он создан для таких устройств, в отличии от многих библиотек допиленных, созданных еще для PC в лохматые года, через костыли говна и палки пытающихся как-то с грехом пополам отрисовать несвойственную ей среду, по пути теряя все преимущества производительности плюсов.
    Хотя, справедливости ради, я видел С++ решения которые на мобилках летают суперски, но это уже вопрос профессионализма, крутой барабанщик и на кастрюлях сыграет много лучше новичка, но учится лучше на хорошем и заточенном инструменте.
    Ответ написан
  • Как оптимизировать рисование линий в WPF?

    cyber_roach
    @cyber_roach
    XAML UX дизайнер INEDIapps
    От нескольких тысяч все что угодно будет тормозить
    Направление указали уже вам, дополню:
    Чтобы не скушать всю оперативу и проц
    читайте про BitmapCache
    https://docs.microsoft.com/ru-ru/dotnet/api/system...
    и RenderTargetBitmap
    https://docs.microsoft.com/ru-ru/dotnet/api/system...
    в UWP кеширование на более верхнем уровне реализовано, там попроще, но в WPF тоже можно сделать хорошо.
    Алгоритм вкратце:
    2 слоя - верхний -там где тыкаете мышкой
    и нижний - кеш
    Добавили линию (на верхнем слое) - рендерите в картинку (верх+низ) - отрисовываете эту картинку на нижнем слое (например через ImageBrush), линию на верхнем удаляете.
    Т.е. как только пользователь закончил фигуру/действие - кешируете.
    Если нужен интерактив на уже нарисованном (например узлы точек подсвечивать), тут сложнее, но тоже возможно (запоминать коодридинаты узлов и при нахождении там мыши - создавать Xaml объект.)
    С интерактивом в подобных алгоритмах как правило много математики.

    Т.е. у вас в оперативной памяти всегда 1 картинка + сколько-то объектов - полилиний.

    К слову, через кеширование кроме рисования можно делать довольно производительные анимации, производительный зумминг, производительный скролл…

    Есть еще вариант: реализовать рисование на DirectX на C++ и поместить контрол. Более нативно и производительнее.

    P/S
    свойсвто IsHitTestVisible
    https://docs.microsoft.com/ru-ru/dotnet/api/system...
    позволяет не реагировать объекту на мышь (т.е. отключает интерактив) это полезно для объектов фона, сильно бустит производительность.
    (т.к. по умолчанию WPF определяет все события интерактива на всех объектах, а их может быть бесчисленное множество, и далеко не на всех нужно иметь реакцию на нажатие/OnMouseMove)
    Ответ написан
  • Какие аргументы для клиента при обновлении сайта (редизайн)?

    cyber_roach
    @cyber_roach
    XAML UX дизайнер INEDIapps
    Важна цель редизайна, а не типографика, структура и прочее.
    Если вы четко обозначите клиенту например:
    - Я могу сделать дизайн так, чтобы в службу поддержки приходило вдвое меньше звонков
    - Я могу сэкономить вам на том-то - том-то порядка 1 млн в год перерисовав вот тут и вот тут.
    - Вот эта фича позволит утереть нос вашему основному клиенту
    и пр.
    Тогда ваши услуги купят сразу, а так просто не понимают чего вы хотите от них и что они получат (в цифрах в итоге)
    Определите цель дизайна ясно и четко с позиции бизнеса (а не дизайнера)
    Ответ написан
  • В каких случаях интерфейс должен быть анимированным?

    cyber_roach
    @cyber_roach
    XAML UX дизайнер INEDIapps
    Анимировать нужно.
    Но нужно считать тайминги на реальном устройстве.
    Не должно быть ожиданий анимации, чтобы нажать кнопку или сделать жест.
    т.е. она вообще не должна напрягать самого быстрого пользователя от слова совсем.

    Анимация должна помогать.
    Посмотрите как работают скроллы.
    Boundaryfeedback когда пользователь доскроллил до конца помогает понять что ниже ничего больше нет.
    Анимация во время загрузки - показывает что приложение живо а не висит намертво. и тд
    Ответ написан