motofan logo
2 страниц V < 1 2        
> 

VNC Server, Попытка компиляции

EXL
сообщение 6.5.2020, 1:05


Rock The Microphone
********

Группа: Администраторы
Сообщений: 2 874
Регистрация: 12.5.2007
Из: г. Новосибирск
Пользователь №: 134 652
Модель телефона: XT894 / XT897
Прошивка: Различные


Настроение:
null



Рейтинг: 4600



fill.sa,
Не в ту степь. У нас дисплей 18 bpp, насколько я помню. Поэтому на этот VNC Server, что я собирал, требовалось наложить специальный сложный патч, конвертирующий цвета. По типу: https://github.com/EXLMOTODEV/Patches/blob/...set-32bpp.patch (красные строки).

VNC Server должен захватывать не только Qt-приложения, а вообще весь /dev/fb0 по идее. Стандартный Qt на MotoMAGX пересобрать с параметром -qt-gfx-vnc невозможно, так как у Qt открыты вроде только заголовочные файлы.
Юзер вышелВ друзьяВизиткаП/Я
К началу страницы
+Ответить
EXL
сообщение 23.4.2022, 16:40


Rock The Microphone
********

Группа: Администраторы
Сообщений: 2 874
Регистрация: 12.5.2007
Из: г. Новосибирск
Пользователь №: 134 652
Модель телефона: XT894 / XT897
Прошивка: Различные


Настроение:
null



Рейтинг: 4600



Дошли руки поковырять клиент и сервер VNC, проблемы с цветностью я исправил, но к сожалению пока не могу разобраться в проблемах производительсности на реальных MotoMAGX-устройствах. У меня получается слишком медленное обновление экрана приблизительно ~1 FPS, при этом этой проблемы нет на эмуляторе MotoMAGX и на реальных EZX-устройствах, что очень странно, код ведь один, а EZX'ы по части процессора ещё слабее чем MotoMAGX'ы.

Битность экрана везде одинаковая -- 262144 цветов @ 18 bpp, на MotoMAGX в драйвере /dev/fb/0 похоже 24 bpp, но дополнительные биты (точнее бит) предназначен для прозрачности и похоже он не используется, либо используется как-то для overlay'ев на IPU, нужно смотреть логи с разных устройств по информации с /dev/fb/0 и /dev/fb/1, возможно там будет ясна причина такого поведения.

К тому же появились проблемы в написании детекта изменений на экране, в классических VNC-серверах при изменениях картинки на экране клиенту отправляются лишь те прямоугольники, которые действительно поменялись, что положительно сказывается на производительности. У меня же в черновом варианте отправляется весь экран, что серьёзно жрёт ресурсы, хотя на том же реальном EZX-устройстве работает приемлимо. И детект изменяющихся прямоугольников этот я вроде написал и он как бы в теории должен корректно работать, но увы: обновляются прямоугольники по координатам криво, похоже что где-то корёжится память, возможно внутри самой LibVNC, поскольку там я использую несколько нестандартную битность в 24 bpp, где частичное обновление наверное работает криво.

И вот здесь возникает дилемма: либо конвертировать каждый кадр из BGR666 (18 bpp) в RGB565 (16 bpp) увеличивая этим конвертированием нагрузку на CPU, но при этом снижая её частичным обновлением экрана, либо оставить 18 bpp и полное обновление экрана, но разобраться в просадке производительности. Кстати, вот сравнение BGR666 (18 bpp) и RGB565 (16 bpp), если приглядеться к градиентам, то видно что качество изображения немного теряется.

Прикрепленное изображение Прикрепленное изображение

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

Да и утилита VINRARUS'а под названием Web Drive ZN5 по сути уже делает всё нужное. Но разобраться с VNC самому бы хотелось.
Юзер вышелВ друзьяВизиткаП/Я
К началу страницы
+Ответить
VNC Server, Попытка компиляции · Motorola ZINE ZN5, ZN5 T-Mobile · Forum
 

2 страниц V < 1 2
Ответ в темуСоздание новой темы
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 28.3.2024, 22:46

Форум живёт: