Android NDK компиляция OpenCPN

19 Feb 2022
by ignat

Для чего Android на яхте?

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

Водостойкое (достигается помещением планшета в водонепроницаемый прозрачный пакет) и с возможностью установки дополнительных программ, которые позволяют скоротать время на вахте. Таких, как Stellarium-android, андроид интерфейс для SunSDR2 радио и т.д.

В предыдущих статьях я написал как сделать стационарное устройство с вложением 300 евро. А сегодня разберём как сделать такое устройство с нулевыми вложениями, при условии, что у вас уже есть любое Android устройство и опыт в кросс-компиляции.

С чего начать?

Начинать лучше всего с краткой инструкции. К сожалению, местами она устарела, а местами очень краткая. Поэтому первым делом предлагаю поставить Android SDK вот таким способом через IDE Eclipse.

Я сознательно не использую Android Студио, так как код который мы будем разбирать был сделан 5 лет назад. Во избежания недоразумений я использую GNU/Linux Debian Wheezy. Так как все библиотеки в этом олдолдстабле дистрибутиве соответствуют Android NDK от 10 релиза (r10e). Полный список всех доступных 64 битных релизов NDK находиться тут.

Будте внимательны, если у вас 32 битный компьютер, то вам не надо заниматься компиляцией тулчейна с нуля (по крайней мере для известного железа, всё уже собрано). 32 битные NDK для вашего целевого компьютера Linux можно скачать тут.

Царский путь к исходникам

Ignat99/OpenCPN at wxqt (github.com)

Ignat99/wxWidgets at wxQT (github.com)

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

Например нужно подобрать подходящий более современный исходный код для OpenCPN под Android, так как существует множество репозитариев с множеством веток кода, которые не совместимы между собой. IMHO Найти более подходящий рабочий исходный код – это отдельная задача.

У меня другая задача – добится стабильной работы на андроиде именно функций и плагинов, которые мною были созданы под GNU/Linux Debian.

Процесс подготовки окружения

Создаём необходимые директории

mkdir ~/Projects/
mkdir ~/Projects/android-ndk/
sudo mkdir /opt/android_toolchain
sudo chown -R <user_name>/<user_group> /opt/android_toolchain

Разархивируем в созданную директорию android-ndk-r10e-linux-x86_64.zip или android-ndk-r10e-linux-x86.bin. И запускаем команду, которая установит кросскомпилятор нужного типа для выполнения:

~/Projects/android-ndk/android-ndk-r10e/build/tools/make-standalone-toolchain.sh \
--toolchain=arm-linux-androideabi-4.8 --platform=android-19 \
--install-dir=/opt/android_toolchain

Установка и использование независимого от IDE тулчейна новых версий невозможна. Поэтому мы используем старые версии.

Кроме того, наше головное устройство навигации имеет тачпанель, которая вместе с SVGA экраном поддерживается только олдолдстабле версией GNU/Linux Debian Wheezy на платформе Olimex OLinuXino A20.

По этим причинам OpenCPN выбрана версии 4.0, так как компилятор как раз соответствует старой версии Debian Linux. И именно в это время была написана поддержка Android для OpenCPN.

Установка Qt5

Qt5 – это известный коммерческий ферймворк, который был “всегда”. То есть существовал до 2004 года. До года секретного начала проекта Android в Америке. И сейчас мы возвращаемся к истокам. В нашем приложении будет микс Qt5 и wxWidget. Чисто гипотетически NDK Android позволяет написать свою операционную систему. Например, Tizen. Но мы этого делать не будем. Тем более уже на этом шаге мы попадаем в зависимость от Qt5, что уже исключает радужные перспективы такой новой ОС. Так как появляется зависимость от сторонней группы разработчиков, которая обычно является фатальной. IMHO

Старые архивы находятся тут. Нужно выбрать тот архив, который соответствует вашей системе. У автора работающего кода bdbcat прописана в настройках CMakeLists.txt директория 5.3. У меня собралось с версией Qt5.3.1, но пришлось в исходниках Qt в заголовочных файлах в подкаталоге QtWidgets поменять название макроса Q_ENUM на Q_ENUMS.

wget https://download.qt.io/new_archive/qt/5.2/5.2.1/qt-opensource-linux-android-x86-5.2.1.run
sudo apt-get install build-essential
sudo apt-get install libfontconfig1
sudo apt-get install mesa-common-dev
sudo apt-get install libglu1-mesa-dev -y
sudo chmod +x ~/Downloads/qt-opensource-linux-x86-5.2.1.run
sudo bash ~/Downloads/qt-opensource-linux-x86-5.2.1.run

Cледуем установкам по умолчанию в инсталляторе Qt. В результате получаем в меню Приложений новое приложение Qt Creator (Opensource). По умолчанию он ставится в папку /opt/Qt5.2.1. Эту папку я использовал для версии без андроида. А нужную версию поставил в папку /opt/Qt.

По ссылке из начала абзаца можно найти информацию как вручную создать запускающий файл Qt-Creator.desktop в папке  .local/share/applications. Часто в Linux библиотеках интегрирование между приложениями осуществляется через вызов этих файлов. Так же наиболее легкие и мобильные оконные менеджеры под Linux используют эти файлы для связывания приложения с расширением и автоматического вызова нужного приложения из wxWidget.

wxWidgets

Это фреймворк, который отрисовывает кнопки и окна, интегрирует принтеры и другие периферийные устройства. Достаточно быстрый, чтоб работать на очень слабых устройствах, подобных Olimex OLinuXino A20.

cd ~/Projects
mkdir wxqt
cd wxqt
sudo apt-get install git -y
git clone https://github.com/bdbcat/wxWidgets.git
cd ~/Projects/wxqt/wxWidgets
git submodule update --init src/zlib
git submodule update --init src/png
git submodule update --init src/jpeg
git submodule update --init src/expat
git submodule update --init 3rdparty/catch

Компиляция с использованием сценария из Qt:

mkdir build_android
cd build_android
export PKG_CONFIG_PATH=/opt/Qt5.2.1/5.2.1/android_armv7/lib/pkgconfig
export CPPFLAGS=-D__ANDROID__
export PATH=/opt/android_toolchain/bin:$PATH
export CC=arm-linux-androideabi-gcc
export CXX=arm-linux-androideabi-g++
export QT5_CUSTOM_DIR=/opt/Qt5.2.1/5.2.1/android_armv7/
../configure --with-qt --build=x86_64-unknown-linux-gnu \
--host=arm-linux-androideabi --enable-compat28 --disable-shared \
--disable-arttango --enable-image --disable-dragimage \
--disable-sockets --with-libtiff=no --without-opengl \
--disable-baseevtloop --disable-xrc --disable-cmdline \
--disable-miniframe --disable-mdi --enable-debug --disable-stc \
--disable-ribbon --disable-propgrid --disable-timepick \
--disable-datepick --disable-xlocale --disable-intl

Перед компиляцией нужно исправить несколько проблем.

Так в файлах

  • include/wx/qt/app.h
  • include/wx/qt/window.h

нужно добавить #include <wx/scopedptr.h>.

В файле include/wx/evtloop.h в 19 строке добавить условие defined( _ _ANDROID_ _) чтоб определялась переменная wxUSE_EVENTLOOP_SOURCE в 1 для нашей директивы при конфигурации связанной с операционной системой _ _ANDROID_ _ .

В файле src/qt/evtloop.cpp в 254 строке добавить в условие || !wxUSE_EVENTLOOP_SOURCE. Этот блок кода был написан в 2003 году нашим соотечественником, который работал для поддержки wx в Виндоус и вызывает метод из проприетарной dll для Windows. То есть это просто устаревшее наследие и надо ещё будет посмотреть как базовый класс этого приложения будет работать с консолью и общим циклом приложений в Android.

Или даже проще закомментировать кусок кода связанный с Виндоус, потому что строкой выше находится точно такой же кусок кода, но уже через класс реализованный в wx без опоры на сторонние dll.

make

Кросс-компиляция OpenCPN

Достаём исходный код из репозитория и переключаемся на ветку исходников wxqt. Попутно убираем на запас новый плагин, в котором один файл по какой-то причине не закоммичен. Этот плагин нас пока не интересует, поэтому отложим его в tmp каталог.

sudo apt-get install cmake
sudo apt-get install gettext
cd ~/Projects
git clone https://github.com/OpenCPN/OpenCPN
mkdir tmp
cd OpenCPN
mv ./plugins/chartdldr_pi ../tmp
git checkout wxqt

Пприводим в соответствие с нашими каталогами файл ~/Projects/OpenCPN/buildandroid/build_android.cmake

#Toolchain and options definition file for OPenCPN Android build


#  Locations of the cross-compiler tools
# this one is important
SET(CMAKE_SYSTEM_NAME Generic)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)

# specify the cross compiler
SET(CMAKE_C_COMPILER   /opt/android_toolchain/bin/arm-linux-androideabi-gcc)
SET(CMAKE_CXX_COMPILER   /opt/android_toolchain/bin/arm-linux-androideabi-g++)

# Location of the generic wxWidgets base
SET(wxQt_Base /home/<ваш_юзернейм>/Projects/wxqt/wxWidgets)

#Location of the specific wxWidgets build (for Qt_Androidd)
SET(wxQt_Build build_android)

#Location of the root of the Qt installation
SET(Qt_Base /opt/Qt5.2.1)

В файле ~/Projects/OpenCPN/src/s57chart.cpp, который отвечает за отрисовку карт в формате CMAP (CM93) в строке 7056 используется вызов сортировки через функцию CMPFUNC, определенную через шаблоны. Компилятор для Андроида спотыкается на этой строчке. Я её просто закомментировал до момента, когда мне потребуется посмотреть на Андроиде отсортированные Маяки.

Аналогично комментируем строчку 1481 в файле routemanagerdialog.cpp.

Так как параметр CMAKE_TOOLCHAIN_FILE на моей машине не всегда корректно интерпретируется кросс компилятором, то мы прямо разместим пару мягких ссылок (ярлыков) на необходимые заголовочные файлы Qt в директории include в wxqt.

ln -s /opt/Qt5.2.1/5.2.1/android_armv7/include/QtGui /home/<ваш_пользователь>/Projecs/wxqt/wxWidgets/include/QtGui
ln -s /opt/Qt5.2.1/5.2.1/android_armv7/include/QtCore /home/<ваш_пользователь>/Projecs/wxqt/wxWidgets/include/QtCore

И компилируем статические библиотеки:

cd ~/Projects/OpenCPN
mkdir build_android
cd build_android
cmake -D_wx_selected_config=androideabi-qt -DCMAKE_TOOLCHAIN_FILE=../buildandroid/build_android.cmake ..
make

Assetbridge

Это почти детективная история в стиле Google. В Реадми файле Андроид проекта OpenCPN указано, что нужна эта библиотека. Написана она одним человеком с именем Стив, но все репозитории удалены. И прямых ссылок Гугл не выдаёт. Но по gist.github.com удалось найти пару человек которые касались этой библиотеки и скрипта, который делает то же самое что написано в этой статье. Хорошо что сохранился форк репозитория создателя этого скрипта, где есть исходники этой библиотеки.

Она состоит из двух частей java и С. Си код просто даёт доступ к временной директории, а Java код позволяет оперативно переносить в заданную директорию необходимые данные. Такие, как значки для карты, иконки и стили для размещения иконок. Все эти перечисленные ресурсы изначально запаковываются в APK файл нашего приложения.

Так же сохранился другой gist-отчёт для одного пользователя из университета в городе Манила. И репозиторий этого проекта. Google возможно намеренно не показывает ссылки связанные с возможной уязвимостью андроид устройств, либо со старыми версиями библиотек.

Так же есть исходники этой библиотеки в ветке android основного репозитария. Эта ветка менялась 2 года назад и является более свежей, поэтому попробуем эту ветку позже.

Нам нужно скопировать этот каталог в аналогичное место нашей ветки. Выполнить команду ndk-build и расположить построенную библиотеку в каталоге ~/Projects/OpenCPN/buildandroid/. Выбор каталога связан с дефолтными настройками в файле ~/Projects/OpenCPN/buildandroid/opencpn.pro

mv ~/Projects/mitchd/OpenCPN/buildandroid/assetbridge ~/Projects/OpenCPN/buildandroid
cd ~/Projects/OpenCPN/buildandroid/assetbridge/
export PATH=/opt/android_toolchain/bin:$PATH
export CC=arm-linux-androideabi-gcc
export CXX=arm-linux-androideabi-g++
export NDK_PROJECT_PATH=/home/<ваш_пользователь>/Projects/OpenCPN/buildandroid/assetbridge/
/home/<ваш_пользователь>/Projects/android-ndk/android-ndk-r10e/ndk-build
cp ./libs/armeabi/libassetbridge.so ..

Эта библиотека даёт возможность C++ коду забирать файлы упакованные в APK (иконки, символы, стили для иконок) из директории на Android устройстве /data/data/org.opencpn.opencpn/cache/.

Сборка финального APK файла

Прежде всего надо отредактировать файл /home/<ваш_юзернейм>/Projects/OpenCPN/buildandroid/opencpn.pro. Следующие строчки требуют изменения:

        wxQt_Base=/home/<ваш_юзернейм>/Projects/wxqt/wxWidgets
        wxQt_Build=build_android

        OCPN_Base=/home/<ваш_пользователь>/Projects/OpenCPN/
        OCPN_Build=build_android

Вот эту дополнительную строчку оставим на последующие эксперименты. Дело в том что например на старом имидже Debian от Olimex A20 с чипом Allwiner OpenGL не работает. Таковы издержки того что эта прекрасная компания (точнее директор компании Цветан Узанов из Болгарии город Пловдив) непосредственно не нанимала программистов, а только поддерживала свободных разработчиков скидками и эвентами, а также иногда приглашала в ресторан, как своих друзей.
Что так же объясняется тем что нанять хорошего разработчика в Пловдиве, выдерживая конкуренцию по зарплате с Американской компанией по безопасности практически не возможно.

LIBS += $${OCPN_Base}/$${OCPN_Build}/lib/libGLU.a

Готовимся собрать динамическую библиотеку и выполняем следующие команды:

cd ~/Projects/OpenCPN/build_android
export PATH=/opt/android_toolchain/bin:$PATH
export ANDROID_NDK_ROOT=/home/<ваш_пользователь>/Projects/android-ndk/android-ndk-r10/
export ANDROID_SDK_ROOT=/home/<ваш_пользователь>/android-sdk-linux
/opt/Qt5.2.1/5.2.1/android_armv7/bin/qmake -makefile ../buildandroid/opencpn.pro -o Makefile.android -r -spec android-g++ CONFIG+=debug

В результате работы qmake будут сгенерированы два файла в каталоге ~/Projects/OpenCPN/build_android

  • Makefile.android
  • android-libopencpn.so-deployment-settings.json

Для того чтоб следующий шаг был успешен. Нужно до компиляции wxWidget откатиться на предыдущую ветку библиотеки libpng и кое-что подсократить в старой версии OpenCPN. Сейчас точно не указываю какие изменения были сделаны, так как они просто связаны с комментированием того что не компилировалось без разбирательства как подружить части между собой.

cd ~/Projects/wxqt/wxWidget/src/png
git checkout libpng16
Далее скопировать 3 файла необходимых из старой весии. 
В основном они связаны с переименованием функций 
и исправление одного бага свзяанного 
с Neon https://forums.wxwidgets.org/viewtopic.php?t=42087

Мы получим libopencpn.so в текущем каталоге размером около 74 мегабайт.

Переходим к финальным командам, ради которхых всё и затевалось.

cd ~/Projects/OpenCPN/build_android
make -f Makefile.android

make -f Makefile.android install INSTALL_ROOT=./apk_build
/opt/Qt5.2.1/5.2.1/android_armv7/bin/androiddeployqt --input ./android-libopencpn.so-deployment-settings.json  --output ./apk_build --android-platform android-19 --deployment bundled

Получаем файл ~/Projects/OpenCPN/build_android/apk_build/bin/QtApp-debug.apk

Установка apk на устройство

Будем использовать командную строку и adb.

cd ~/Projects/OpenCPN/build_android/apk_build/bin
~/android-sdk-linux/platform-tools/adb kill-server
~/android-sdk-linux/platform-tools/adb start-server
~/android-sdk-linux/platform-tools/adb device
~/android-sdk-linux/platform-tools/adb uninstall org.opencpn.opencpn
~/android-sdk-linux/platform-tools/adb -s <id вашего Adroid устройства> install ./QtApp-debug.apk  

В дальнейшем надо попытаться подобрать лучшие (максимально новые) версии wxWidget и OpenCPN. Но максимально совместимые с нашим кодом на основе OpenCPN 4.0

Несколько наиболее важных частей – Командная строка, libpng, wxSound были в стадии обновления и несколько лет эту часть кода в этих версиях никто не менял. Поэтому возможно придётся сделать промежуточный патчь для OpenCPN нашей версии, но который совместим с максимально новым wxWidget и Qt именно под Android.

Так как проект OpenCPN это по сути 4 различные версии кода под основныне операционные системы. Они отделены друг от друга директивами #define и #if #else #endif. Одна из которых Android.

Публикация релиза на Google Play Store

В инструкции написанной автором, другой пользователь GitHub (возможно физически это тот же человек), кто продолжил работу над кодом для Android обрезал часть связанную с кодами.

Во первых эта процедура устарела для новых приложений под Play Store, а во вторых она содержит часть индивидуальных ключей автора. Но я решил привести ссылку на неё. Возможно кто-то решит повторить эту часть, либо подскажет лучший мануал по этой теме, актуальный на сегодняшний день.

Теги:

Хабы:

Комментарии 20

Как начинающий пользователь яхты хочу спросить, в чем преимущество OpenCPN? В сравнении с навиониксом на планшете и стационарными картплоттерами типа всяких гарминов.

Благодарю за вопрос.

Если бы вы посмотрели предыдущие статьи, то заметилибы что я воовсе не делаю программу навигации, я по совместительству автоматизирую производство на том что мне интересно.

Нам не нужен OpenGL. И у меня к нему в основном спортивный интерес.

Так же бы вы заметили что программа была использована на Olimex OlinuXino a20, потому что я это сделал ещё 5 лет назад и это было довольно экономное (25 евро) и производительное решение.

Сейчас меня привлекает эта система именно как пример использования wxWitgets вместе с Qt и особый фреймворк OpenCPN котороый подходит для задачь логирования и парсинга в реальном времени данных с UART (или COM портов попросому).

Короткий ответ – привлекает лицензией, скоростью, языком С, наличием плугинов и естественно полностью открытым кодом, который можно переделать например в спортивный автопилот или другие специфические задачи. Тоесть возможностью модификации кода под свои нужды.

Спасибо!

В целом понял, пойду другие статьи почитаю.

>> спортивный автопилот
А чем спортивные автопилоты отличаются от обычных круизёрских?

Если предпочитаете в исходном коде то тут tactics_pi/src at master · bdbcat/tactics_pi (github.com)

Если с картинками Tactics [OpenCPN Manuals]

Если моими словами. То ветер меняется и волны меняются. А яхта в долгой гонке идёт сутками. Поэтому в каждой точке исходя из 2-х дневного прогноза можно определить несколько путей с примерно одинаковым временем. Но из за погоды, бывает важно пройти быстро или вообще не заходить в штилевую зону.

Так вот тактические дисплеи строят оптимальный теоретически предсказанный путь исходя из полученных свежих данных в режиме реального времени.

На коротких дистанциях для спортивных лодок важны только точные обновлённые карты, чтоб тупо в свежеобразовавшуюся помеху невьехать. Причем точность должна быть менее 5 метров, чтоб можно было вписаться в манёвр до помехи.

Для этого дисплеи ставят в кокпите. (Потому что пока бежишь от штурманского столика на пост, яхта может и 10 метров и даже несколько корпусов пройти при свежем ветре). Именно поэтому и возникла необходимость в Андроид устройстве, которое способно работать и с картами и с различными плугинами.

Круизёры при заходе в порт в очень свежий ветер. Когда надо обойти мели при входе, находятся практически в положении спортсменов. Надо расчитать маневр и пройти на безопасной глубине возле мели. Так как ветер часто наваливает яхту на мель.

Подробнее по ссылкам выше.

Про эпюры ещё забыл добавить. Яхты бывают разные. Некоторые лучше бакштагом идут, а некоторые под фордевинд заточены (дракары) или бейдевинд (мотосейлеры). Причём зависит и от поставленых парусов и от волнения. Все эти данные учитываются при прогнозе.

В свое время, будучи студентом очень сильно помучался в попытках собрать OpenCPN под андроид, и безуспешно. На одной из стадий была ошибка и я не знал как её решить. На, cruisersforum создал тему, и мне по этому поводу коротко ответили что мол версия для андроид более не бесплатная. Мне в общем то нужен был минимальный функционал (отображение карт s57, судна и ais целей) для научной лаборатории, где я тогда уже параллельно работал. При этом требовалась поддержка большого количества платформ, в том числе Android и желательно IOS. С этого момента началась моя эпопея с созданием собственного картографического движка. В качестве GUI выбор сразу пал на Qt. Сначала рендер карты осущетвлялся при помощи QPainter, затем полностью переделан под OpenGL (cовместимость с ES 2.0). Сейчас хочу и вовсе “оторвать” весь код от конкретного фреймворка (специфичные классы и методы) со всеми его лицензиями, чтобы для работы требовались лишь OpenGL контекст и ввод. Мне вообще кажется что OpenCPN довольно сильно устарел: wxWidgets с его лишь частичной кроссплатформенностью; первобытный fixed-pipeline OpenGL, чего только стоят glLineWidth и GL_LINE_STIPPLE.

Благодарю за диалог.

В новой версии, поддержкой которой занимался человек, который удалил ключи автора из репозитария

Correct GL Vector symbol extents to allow cursor pick on entire rende… · OpenCPN/OpenCPN@b939f30 (github.com)

Он же отказывался отвечать на вопросы куда делся вот этот файл

https://github.com/bdbcat/wxWidgets/blob/master/include/wx/qt/private/wxQtGesture.h

Который тянет за тсобой wxGLCanvas для андроид.

Вообщем действительно собрать с ключём OpenGL версию OpenCPN под Android это проблема. Вот он практически отказался работать бесплатно. Идея была в том что все сами будут присылать автору деньги, но видимо она не сработала по причине что рынок очень узкий и мало людей ходят на яхте и ещё меньше используют OpenCPN.

Android version – segment violation · Issue #826 · OpenCPN/OpenCPN (github.com)

Android version – segment violation · Issue #826 · OpenCPN/OpenCPN (github.com)

If this is the most current version, I believe it should be wxWidgets 3.1.1 which is what the OS linux, windows and macos versrion 4.99 uses, otherwise if it is or Opencpn version 4.8.2 it should be wxWidgets 3.0.2 . You do not state which version you are trying to compile.

Implement wxGestureEvent support for wxQt · wxWidgets/wxWidgets@a3d58da (github.com)

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

Кроме того все ветки и теги Android в официальном репозитории OpenCPN (начиная с первого Release android_v1.0.0 · OpenCPN/OpenCPN (github.com) ) строго для кода wx более позднего чем 3.0.0. Например можно попробовать использовать wxWidgets 3.0.2

Я же использовал другой репозитарий в этой статье bdbcat/wxWidgets: Cross-Platform GUI Library – Report issues here: http://trac.wxwidgets.org/ (github.com)

Основная проблема это изменение реализации wxGLCanvas. Так же подключения дополнительных возможностей вокруг шрифтов и настроек опций OpenGL.

Qt это фреймворк кроссплатформенного софта. У него есть ГЮИ (GUI) – Qt Creatot

GUI в этом контексте это wxWidget

А рендер и фреймворк это OpenCPN (в котором уже есть конфигурация, списки объектов, принтера, модульная система драйверов сенсоров и дашборд через плагины).

Если вам нужен быстрый рендер, то почему не использовать что то типа CUDA? Или сразу Unity3D?

Вообщем вы определитесь с терминами. То что вы перешли на Qt связано с тем что все перешли с GTK+ туда после смены лицензии Qt около 2014 года?

Под GUI я имею в виду средство для создания кросплатформенного графического интерфейса. И в этом смылсе я противопостовляю wxWidgets – Qt. Понятно что Qt это больше чем просто GUI, но тем не менее это основная его задача – создание кросплатформенного софта с графическом интерфейсом.

Выбрал Qt в перую очредь из за большого количества поддерживаемых платформ и простоты сборки. Поменял таргет в среде(Qt Creator это все же просто среда разработки с точки зрения терминологии) c Windows на Android и вот ты уже собираешь проект под андроид или IOS. Без проблем. К тому же сам графический инфтефейс куда более кастомизируемый и визуально приятный. Особенно QML. wxWidgets в этом плане выглядит совсем уж аскетично.

CUDA же это про параллельные вычисления на картах NVIDIA а не про рендеринг, развне нет? Unity все-таки игровой движок, и скриптуется C# а не C++. Пришлось бы интегрировать С++ библиотеки (а большая часть библиотек из этой предметной области написана именно на C/C++ ). К тому же опыта работы с Unity и С# у мне не было и нет.

Меня в общем то в Qt устраивает все. Кроме лицензии пожалуй. LGPL с одной стороны позволяет использовать софт в коммерчеких целях, но там какие-то сложные моменты, типа того что нельзя линковать библиотеки статически, а IOS зарпещеат линковаться динамически, и еще много тонкостей и органичений.

По поводу быстрого рендеринга: я использую непосредственно OpenGL/ES, объединяю всю похожую геометрию в группы(batch). Все символы на карте также рисуются за 1 вызов. Линии тесселируются на CPU, а сглаживаются во фрагментном шейдере. В итоге производительность раза в 3 выше чем в OpenCPN при значительно более качественной графике. Навряд ли можно сделать быстрее, чем с помощью непосредственно графического API. https://www.youtube.com/watch?v=msDhjk1dndk

Производительсность не может быть выше в 3 раза. Возможно у вас был кастрированный OpenCPN на сравнении.

И там и там OpenGL. Если говорить что OpenCPN медленние, то надо точно указывать со ссылкой на профаил в каких именно операциях он теряет. Может это просто свойство той платформы\железа на котором вы тестовый запуск делали.

Кроссплатформенность именно из за применения wxWidgets достигается. Причём найтивная. Потому что несколько разработчиков в различное время по сути сделали wxWidgets аналоги под основые 4 операционные системы. Кроме того, он есть на почти всех языках программирования в виде вызываемых библиотек.

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

Из вашего видео видно, что вы сравниваете аппаратное ускорение с симулятором софтварным. Вообщем очень жаль, что вы даже этого и не заметили.

К слову на хороших современных аппаратных ускорителях можно смотреть 3D сцену одновременно с нескольких точек зрения.

Моё мнение, что если собрать правильно OpenCPN c поддержкой ускорителя, то разница в скорости будет связана только с отрисковкой дашборда, которого у вас на экране нет. То что стоит сбоку от карты – это отдельная аппаратная область вывода.

Тут статья про OpenCPN. Давайте больше не отклонятся от заявленной темы. OpenCPN это не про отрисовку карты, а про прокладку пути, редактирование списков и подключение в одном дашборте кучи инструментов. Познакомтесь с руководством по OpenCPN.

И я понимаю вас, что очень сложно без привычки разбираться в чужом коде, что гораздо проще написать своё. Но когда написанное с нуля достигнет такого же функционала как OpenCPN оно будет уже никому не нужно, так изначально ориентировано на OpenGL, который был сделан просто для потдержки VRML, а не для отрисовки реалистичных сцен. Для которых уже используют CUDA вычисления и более современные технологии.

CUDA это не совсем чистый СИ.

А если вам нужна скорость настоящая надо смотреть в сторону современных ПЛИС (FPGA).

С чего Вы взяли что в OpenCPN на видео отключего ускорение OpenGL? Оно включего по умолначни, в меню-> отображение -> дополнительно-> использовать ускорение OpenGL. Сравнение вполне коррентное. OpenCPN 5.2.4 из официального сайта, я его не собирал самостоятельно. Без ускорения было бы в районе 5 FPS (я сейчас попробовал отключить). На видео видно что в некорых сценах FPS падает ниже 60, судя по плавности, счетчик почему-то не работает, хотя включен в опциях (карта GTX 1060). В моем рендере FPS почти никогда не опускатеся ниже 180 даже в самых нагруженых сценах, в среднем больше 200. Настройки парамтеров отображения карты оналогичны. Сравнивал производительность на разных устойствах. Отошение примерно такое, как я сказал.

А как функционал влияет на fps? Он есть, где-то там. Но не включен же постоянно, т.е. не влияет ни на время формирование кадра ни на отрисовку. Я не думаю что дашборд вообще может как-то сущетвенно влияеть на производительность. По сравнению с картой, сотоящей из миллиона полигонов, сотен тысяч вершин, и тысячи спрайтов, одновременно находящихся на экране это несущественно. Ровно как и наличие диалогов с формами. Как факт их наличия может оказывать влияние на производительность, особенно в части отрисовки карты? При сравнении я стараюсь создавать одинаковые условия, ни там ни там не открыти ни диалоги, ни дашборды. И кстати, сайдбар сбоку: что значит отдельная область вывода? Он отрисовывется в том же контексте, что и вся карта. QML сначала передает контекст мне, я рисую все что нужно – а потом, сверху уже рисуется весь интерфейс. Но я не думаю что он “съедает” больше 1 FPS.

Разница в производительности обосновата как минимум тем, что OpenCPN не объединяет похожую геометрию в batch. Тысячи объектов на экране = равно тысячи вызовов отрисовки. Batching – это самый очевидный способ оптимизации рендера. Использует glBegin – glEnd вместо, того чтобы рисовать геометрию из вершинного буфура (VBO). Совершенно не задействуется многопоточность при подготовке кадра. Вот она и трехкратная разница в производительности . Я в коде OpenCPN где-то на протяжении года ковырялся и вполне себе разобрался. Изначально именно на его базе делался весь функционал, для нужд лаборатории. На видео 2018 года еще осталась та самая версия на базе OCPN.

https://www.youtube.com/watch?v=SwgmZaP3HGU

У вас отключена аппаратня OpenGL для OpenCPN. Разбирайтесь сами.

По поводу своего спама пишите свою статью.

OpenCPN это работа с базой данных, форматами карт, внешними устройствами и источниками данных. Так же связь с другими яхтами и т.д.

Прочитайте вначале мануал прежде чем тут еще раз что либо говорить.

OpenCPN Books/Manuals

И кстати, я до сих пор не могу понять причем тут CUDA? Точно ли ту СUDA, Вы имеет в виде, что SDK от Nvidia? CUDA – во-первых работает только на картах Nvidia, во-вторых, предназначена для выполнения параллельных вычислений общего характера и не имеет вообще никакого отношения к рендеру. Это тоже самое что вычислительный шейдер. Или OpenCL. Вычислительный шейдеры давно есть в современном OpenGL/ES, как Вы предлагаете их использовать в данной задаче? Разве можно CUDA вообще противопоставлять графическим API, типа OpenGL?

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

Что значит спам? Я оставил один единсвтенный комментарий под этой статьей, в котором рассказал своем опыте работы с OCPN и сборки под Android. Дальнейший диалог Вы развиваете сами. Сами же затронули вопрос о “быстром рендере” и производительности. И эта ветка диалога именно об этом.

Что касается грамотности, я уверен что это Вам нужно внимательно изучить хотя бы терминилогию, и понять что же из себя предсвляет CUDA и в каких отношениях она находится с графическими API. Я не уверен что вообще могу Вас понять. Намешали все вместе, карты, воксели, CUDA, OpenGL. Как это связано? Скажите честно, Вы имели опыт работы с OpenGL и в полной мере понимаете о чем идет речь?

Моя “поделка” (почему в таком унизительной тоне?) выполняет ровно те задачи, для которых создавалсь и обладает ровно тем функционалом, который от нее требуется. Почему одна должна повторять функционал OpenCPN? Это два разных софта, котоые я сравниваю лишь в части производительности рендера.

Не хотите продолжать диалог – не продолждайте более. Я лично не привык оставлять обвинения в мой адрес неотвечеными.

Сложно говорить с технически безграмотным в области компьютерных вычислений человеком.

Вам никто ничего не обязан. Вы официально тролль и это крайнее сообщение вам.

Вам сейчас не более 29 лет и да, вы IT самозванец без опыта. Это вам мой фидбак. Хотели получить. Получите и распишитесь. Джуниором я бы вас не взял, и практикантом тоже. И стажёром. И даже учеником за доплату.

Для того чтоб OpenGL заработал в Android, нужно собрать соответствующие библиотеки под ARM.

GL/gl.h, Qt5 and arm: FTBFS (debian.org)

Basically the problem might boild down to the fact that Qt5 is built using es2 
instead of the "desktop" opengl which, to the best of my knowledge, it's 
standard OpenGL 2.0.

Ответы:

Re: GL/gl.h, Qt5 and arm: FTBFS (debian.org)

Re: GL/gl.h, Qt5 and arm: FTBFS (debian.org)

И это не столько проблема закрытых драйверов, сколько проблема закрытых Даташитов. Потому что там информация о багах внутри реализации графических ядер и их встраивания в SoC. Корпорации на момент выпуска устройства скрывают косяки в изделии, даже от большинства своих сотрудников (по крайней мере младших чем 4 ранг и работающих в другой области кода).

А косяки производителя, закрытые драйвера + особенности и тайны встроенного гипервизора создают поистине гремучую смесь. И 5 лет назад приходилось выбирать Qt5 или аппаратный OpenGL …

Minecraft Edu © 2024