Платформа разработки графического интерфейса приложения

Исходя из опыта C ++ и MFC, есть ли лучшая (поддерживаемая / настраиваемая) платформа для разработки графического интерфейса приложения?

Мы разрабатываем промышленные приложения (машинное зрение), где:
-критично к производительности (в основном обработка изображений в атм ЦП, но следующим будет графический процессор)
-Низкоуровневый аппаратный интерфейс (внутреннее устройство PCI, фреймграббер, движение card)
-Визуализация данных в реальном времени (изображения / статистический график)
-Дорожная карта будущего включает сетевые возможности для распределенной обработки и удаленного доступа.

Кроссплатформенность не будет для нас важна, поскольку система работает в контролируемой среде (клиент заботится только о том, работает ли система и получает ли она результат).

Также существуют опасения по поводу стоимости миграции (сторонние зависимости, стоимость обучения разработчиков и обслуживающего персонала).

Редактировать
Уточнение по поводу «обработки изображений», упомянутого выше:
Я имею в виду «изображение» (2D-информация в матричном формате), а не графическое изображение (обычно 3D-векторизованное). В настоящее время мы используем стороннюю библиотеку изображений (для обработки пространственной области, такой как сегментация, OCR / OCV, морфология, сопоставление с образцом) и включаем нашу логику результатов.


c++ user-interface platform mfc
person YeenFei    schedule 17.09.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Что я делал раньше при разработке научного приложения на C ++, так это то, что оно будет разрабатывать его полностью под консольным приложением. Консольное приложение может принимать различные типы команд с пользовательской клавиатуры и выполнять соответствующие действия. Например :

image_processor > load input.png
image_processor > save out.png

В этом плане хорошо то, что я могу на 100% сконцентрироваться на дизайне алгоритма, не беспокоясь о том, как вписаться в структуру графического интерфейса. Либо они MFC, либо QT.

В конце концов, вместо того, чтобы принимать ввод из потока ввода с клавиатуры, я просто подключу STDIN моего консольного приложения к каналу связи приложения с графическим интерфейсом. Затем мое приложение с графическим интерфейсом будет выполнять строковую команду, чтобы разговаривать и получать обратную связь от консольного приложения.

Угадайте, что я использую для разработки графического интерфейса? Java Swing :)

Думаю, я придерживаюсь подхода Unix. Посмотрите, что говорит Иоиль:

Suppose you take a Unix programmer and a Windows programmer and give them each the task of creating the same end-user application. The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core. This way the main operations of the application will be available to other programmers who can invoke the program on the command line and read the results as text. The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface.

Я понимаю, что, применив подход Windows, вы получите более user friendly приложение. Однако, если ваша главная задача - хорошо написать сложный алгоритм, а графический интерфейс - второстепенный, я бы посоветовал вам перейти на подход Unix.

person Cheok Yan Cheng    schedule 18.09.2010

arrow_upward
3
arrow_downward

Если вам нужна критически важная для производительности обработка графики, то C ++ / DirectX или C ++ / OpenGL - ваши лучшие ставки, без сомнения. C ++ / DirectX, возможно, более удобен в обслуживании из двух.

Тем не менее ... в зависимости от фактической обработки, которую вы выполняете, вы можете подумать о перемещении частей вашего пользовательского интерфейса на более удобную платформу. .NET framework / WPF может делать довольно удивительные вещи, а с хорошей реализацией шаблонов, таких как MVVM, может быть потрясающе обслуживаемым. То же самое с сетевой стороной; WCF абстрагирует многие распространенные протоколы от кода, делая сетевой код более чистым и удобным в обслуживании. Вы даже можете написать свой уровень трансляции между неуправляемой обработкой и управляемым уровнем на C ++ / CLI.

Это сказано, все это очень субъективно. Я не могу сказать достаточно из ваших пунктов, чтобы сделать хорошее суждение о том, можете ли вы переложить часть или даже всю свою обработку на .NET / C #. Об этом стоит подумать, но моя интуиция подсказывает мне, что это, вероятно, не лучший вариант.

person Randolpho    schedule 17.09.2010
comment
Лично я сейчас переписываю графический интерфейс MFC на C # / WPF. Я не говорю, что код C ++ был хорошо написан, но я считаю, что очень легко написать код на C # / WPF, который будет более быстрым и более отзывчивым, чем существующий графический интерфейс MFC. Отчасти это связано с тем, что в C # исключительно легко выполнять параллельные операции с помощью нескольких строк кода, что потребует от вас сотен, если не тысяч строк кода на C ++. При этом элементы управления MFC, похоже, отстают от WPF в аналогичных задачах, таких как работа с ComboBoxes, которые имеют большое количество элементов. - person Nathan Ernst; 17.09.2010
comment
@Nathan: Да, я тоже большой поклонник. Для чего-либо, кроме, скажем, 3D-игр, я обычно рекомендую C # / WPF. В этом случае я нахожусь на заборе исходя из его требований. Вероятно, это можно было бы сделать на C # / WPF - я бы определенно хотел сделать это на C # / WPF, звучит как забавный проект - и это было бы достаточно производительно, но ... было бы это производительно достаточно? Я просто не знаю. - person Randolpho; 17.09.2010
comment
@Randolpho, согласен, без подробностей ничего не скажешь. Мой опыт показывает, что аргумент, что мы не можем / не должны писать на C #, потому что C ++ быстрый, обычно является ложным, поскольку сравнительный код C ++ обычно дерьмовый и неэффективный. Предостережение, это обобщение, и я пишу в первую очередь на C ++. Но я вижу много быстрого кода cough shit cough. Я вижу, что большую часть кода C ++ я могу писать на Python быстрее. Тем не менее, восприятие менеджмента может оказаться нелегким делом. - person Nathan Ernst; 17.09.2010
comment
Следует также отметить, что прежде, чем я убедил руководство в использовании питона, нам в голову пришло метафорическое ружье. У меня было 3 недели, чтобы написать с нуля, без внутренних библиотек, приложение для переноса финансовых позиций в произвольном формате центральному клиринговому партнеру. Они были убеждены, когда я мог перенести 1 миллион позиций менее чем за 10 минут, а код был достаточно гибким, чтобы адаптироваться к быстро поступающим изменениям требований. - person Nathan Ernst; 17.09.2010
comment
@ Натан Эрнст: вы не получите от меня никаких аргументов по поводу производительности. Для 99% всех вариантов управляемый JIT-код в форме C #, Java или Python (с Unladen Swallow, PyPy или Psycho) так же, если не часто, быстрее, чем (для длительно выполняющихся процессов) неуправляемый код. Конечно, остаются оговорки, особенно в отношении графики, но ... да. - person Randolpho; 17.09.2010
comment
Кроме того, @YeenFei, на основе вашего редактирования, я думаю, что C # может помочь, хотя фактическая обработка, которую вы выполняете, будет сложной и трудной на любом языке. Если ваша библиотека обработки зрелая и стабильная, возможно, не стоит с ней связываться. - person Randolpho; 17.09.2010
comment
@Randolpho, библиотека обработки - это зрелая CoTS, а некоторые даже имеют поддержку .net в более новой версии. Тем не менее, наш слой BL (логика @result) является довольно устаревшим (и длинным, конечно!), Что меня беспокоило, требуется ли его переносить на .net - person YeenFei; 18.09.2010

arrow_upward
3
arrow_downward

Как поклонник Qt, было бы упущением не упомянуть об этом.

  • Хотя кроссплатформенность не является одним из ваших критериев, это хороший бонус.
  • Qt также имеет хорошую поддержку видеооборудования через OpenGL (хотя я не уверен, что это поможет с оборудованием для захвата).
  • Это открытый исходный код, так что вы можете пачкать руки сколько угодно.
  • Это очень настраиваемый.
  • Он активно развивается и имеет большое сообщество.
  • У программистов MFC не должно возникнуть особых проблем с ускорением.

Вам также следует прочитать некоторые из этих вопросов и ответов:

Хорошая библиотека графического интерфейса C ++ для Windows https://stackoverflow.com/questions/610/gui-programming-apis.

person Arnold Spence    schedule 17.09.2010
comment
Я согласен с Арнольдом. Qt - хороший выбор в наши дни. Я использовал его на своей последней контрактной работе для медицинского устройства, и это нормально. Мне особенно понравился механизм сигнального слота. - person ExpatEgghead; 17.09.2010