Лёгкий/быстрый интерфейс для ARM платформы (OpenGLES)

[MX_Master]

В связи с популярностью одноплатных ПК, пора подумать о том, что интерфейс LinuxCNC должен учитывать возможности мобильных видео чипов. Как пример, отрисовку траектории желательно делать средствами OpenGL ES. А в целях убыстрения работы интерфейса желательно перескочить с python на нативный C. Кто что думает по этому поводу?

[Мастерю]

MX_Master, тема интересная, однако возникают
Вторые мысли вслух - а насколько уж так сильно востребована визуализация на самом станке?

Программист, готовящий УП в какой-либо среде разработки обязан провести эту визуализацию, дабы проверить и окончательно убедиться, что подготовленную им УП можно передавать в производственный цикл. А вот, насколько так уж нужна эта визуализация в процессе производства, оператору станка?

Еще более явно этот вопрос касается любителей, как раз тех, кто чаще всего использует ARM в своих, часто собственноручно собранных станках. Мне как-то не совсем понятно, зачем мне, подготовившему УП, уже видевшему эту визуализацию в процессе создания УП, потом, после переноса в контроллер станка еще раз запускать эту визуализацию? Я больше за то, чтобы в УП была нумерация строк, а контроллер станка непрерывно фиксировал/запоминал номер выполненной строки. Это дает возможность в случае сбоя знать с какого места можно продолжить выполнение.

Все вышесказанное ИМХО.

[aftaev]

Программист, готовящий УП в какой-либо среде разработки обязан провести эту визуализацию, дабы проверить и окончательно убедиться, что подготовленную им УП можно передавать в производственный цикл. А вот, насколько так уж нужна эта визуализация в процессе производства, оператору?

Запаришься в САМ программе усе моделировать. Например: для токарки нужно усе оправки нарисовать, показать под каким углом державка стоит, а если какая либо хитрая оправка то и ее рисовать и тд... На токарке довольно часто: зажимаю заготовку, загружаю УП, привязываю ноль и гоню резец в конец обработки. Смотрю на визуализацию и на реальную позицию инструмента.
надо было внутри детальки проточить канавку. Для этого нужно было руками повернуть детальку так чтобы зашел резец, включить обороты и проточить. Смысла писать УП для этого не было. По визуализации и протачивал.
Далее визуализация помогает на станке стартануть с нужной строчки УП. На визуализации подсвечивается.
На плазме постоянно по визуализации ловим откуда резать.
Визуализация на станке удобная штука, можно жить конечно и без нее.

[MX_Master]

Вопрос о показе траектории не стоит, потому что он уже решён. Кому не нужно, просто, выключают это дело и всё (: Как правильно заметил Александр, когда составляешь мини УП прям на стойке, или отлаживаешь какую-то операцию вручную, визуализация реально рулит.

Я, просто, планирую фронт дальнейших работ по ARM платкам с LinuxCNC на борту. Если такой открытый проект будет неинтересен пользователям, знатокам и коллегам-прогерам, я сделаю его самостоятельно, но оставлю его для своего проекта казахского сименса (:

[selenur]

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

[MX_Master]

Короче говоря, в качестве эксперимента попробую на чистом C и GTK+ накатать шаблончик тырфейса. У GTK+ с какой-то 3.22.x версии есть возможность рисовать средствами OpenGLES. Добавлю в отрисовку кучу примитивов и посмотрю как это будет работать на апельсиновом MALI 400.

[Maxekb77]

ага и счет для сбора денеххх

[NKS]

Что то мне кажется, не зря на linuxcnc.org ребята всё активнее и активнее "толкают" qtpyvcp.

[MX_Master]

Что то мне кажется, не зря на linuxcnc.org ребята всё активнее и активнее "толкают" qtpyvcp.

Они не собираются переходить на мобильные платформы (: По крайней мере, не сейчас. QT взят на вооружение, потому что с ним легче работать, есть продвинутый задел на мультиплатформу + поддержка OpenGLES. Но при этом QT ни разу не лёгкий и нифига не быстрый.

ага и счет для сбора денеххх

Вроде, взрослый человек, а постоянно чем-то недоволен (:

[Serg]

Они не собираются переходить на мобильные платформы (: По крайней мере, не сейчас. QT взят на вооружение, потому что с ним легче работать, есть продвинутый задел на мультиплатформу + поддержка OpenGLES. Но при этом QT ни разу не лёгкий и нифига не быстрый.

По этим параметрам GTK+ и QT равнозначны, вопрос чисто религиозный.

P.S. подобные метания до добра не доводят...

[MX_Master]

По идее, для мобильной платформы юзать бы надо не QT/GTK, а что-то попроще да побыстрее (:

А в идеале, надо начать не с выбора GUI и прочих кнопочек, а прямо с визуализации. И если аппаратная отрисовка будет не так быстра, как я ожидаю, тему про QT/GTK можно смело сворачивать ))

[Serg]

По идее, для мобильной платформы юзать бы надо не QT/GTK, а что-то попроще да побыстрее (:

Xt, Motif, Fltk - куда уж проще и быстрее?..

А в идеале, надо начать не с выбора GUI и прочих кнопочек, а прямо с визуализации.

Рисуй прямо во фреймбуфере - куда уж быстрее... А кусок фрембуфера засунуть в любой "контейнер" особых проблем не составит.

[NKS]

Кстати, по поводу отрисовки, vtk backplot для QTvcp на linuxcnc.org оценивают (судя по отрывочным постам),как "гораздо более шустрый чем старый гремлин".

[Serg]

Зная как там это всё внутри устроено я чёта сомневаюсь в компетентности этих оценивателей...
Кстати, кто-нибудь тут уже использовал профайлер для исследования имеющейся отрисовки?
И кстати, а кто-нибудь тут понял, что я только что спросил?

[NKS]

Администрация запрещает материться (в любом виде)

[daemon78]

И кстати, а кто-нибудь тут понял, что я только что спросил?

Выявить наиболее затратные по ресурсам места, чтобы понять где и на что уходят ресурсы или что то другое имелось ввиду?

Администрация запрещает материться (в любом виде)

Хотел ответить, но вспомнил, что у меня уже два предупреждения.

[MX_Master]

Кстати, кто-нибудь тут уже использовал профайлер для исследования имеющейся отрисовки?
И кстати, а кто-нибудь тут понял, что я только что спросил?

Да, вроде, и без исследований видно, что с отрисовкой что-то не так. Это ж насколько медленными были п современные игры, если б в каждую сцену мы вставляли абсолютно все объекты, что у нас есть. Никакой памяти и производительности на такое не хватит. Поэтому когда мы открываем довольно большую УП, процесс отрисовки может запросто съесть все наши немногочисленные ресурсы.

Внутрь текущей визуализации я не лез, ибо я не большой любитель python

Профайлер - слышал, но не видел (:

[Serg]

Да, вроде, и без исследований видно, что с отрисовкой что-то не так.

В каком именно месте?.. Ну чтоб понимать чего именно ему не хватает и как исправить...

[MX_Master]

Без профайлера могу только гадать (: лично мне не нравится, что за отрисовку отвечает python

[MX_Master]

Немного побродил по тырнету и наткнулся на uGFX и LittlevGL, оба умеют работать с framebuffer. Выглядят красиво, жрут очень мало (: