Когда хочется красивый GUI, а gpu нет

    Обычно для рабочих утилит не требуется вменяемый UI, с кнопками, списками, окнами, поддержкой мыши и прочей мелочевкой, большинство рабочих «хотелок» можно упаковать в скрипты и иногда запускать их с параметром --help, и так будет даже правильней с точки зрения настройки и масштабирования. Все становится хуже, когда тулами начинают пользоваться не только команда разработки, но и сторонние люди. А они не всегда готовы вникать в стройные мысли, уложенные в строчки кода. И тогда приходится городить UI, а он у разработчиков выходит обычно простой, квадратный, функциональный и совсем скучный. Некоторое время назад я работал над небольшой системой управления вентиляцией/обогрева/камерами и еще того «что придумает вон тот дядечка в желтой каске» для подземной автостоянки.



    (Здесь была картинка с UI системы, но разработчик попросил её убрать. Если вам не хочется читать о прогулках по граблевому полю, то ссылки на гитхаб в конце статьи)

    Система была построена на китайском нонейм SoC, для которой производитель расстарался портировать SDL фреймворк первой версии. Внутренние тулы и скрипты доработали до такой степени, что они превратились в развесистый и «красивый» макет c вкладками, списками, попапами, тенями, градиентом, прозрачностью и другими плюшками.

    Для реализации всех красивостей был выбран nanogui, простой и неприхотливый, и при этом «могущий» всё что было нужно. Ровно было на бумаге, да забыли про OpenGLовраги. Почти полностью реализованный UI системы управления стали запускать на железе, а там черный экран, все инициализации OpenGL3 проходят без ошибок, буферы ставятся, а шейдеры компилятся, но нет… черный экран, под каким углом не посмотри.

    Сначала грешили на мои кривые руки, потом на руки Антохи-разработчика, ответственного за драйвера и железо, потом запустили тестовый пример рендера треугольника из состава сдк SoC, и снова черный экран, документацию и примеры как обычно читают в последнюю очередь.

    Что-то тут неправильно подумали мы с коллегой и пошли сначала на китайский форум, а не найдя там внятных ответов уже и к разработчику, ответ был неутешительный, реализации opengl нет, и скорее всего не будет, потому что линейку снимают с производства.
    — А как же SDL фреймворк? — спросили мы
    — Рисуем попиксельно в видеопамять. — Ответили нам наши китайские друзья.

    В тот день я увидел грустные глаза программиста, который подсчитывает сколько LoC он отправит в /dev/null. Но бросать уже готовое решение было очень обидно, (в интернетах найдется всё) оказывается жить без OpenGL в nanogui можно на software рендере.

    Только жить получается очень медленно, на большом ПК пару секунд на фрейм, на китайском чуде инженерной мысли уже примерно 20-25 секунд для отрисовки. Тогда решили рендерить не весь UI сразу, а только нужные (измененные) части виджетов, но даже в таком режиме, со всеми хаками и оптимизациями выходило больше 10 секунд на один фрейм, нежизнеспособно…

    Покурив немного примеры сдк выяснили, что копирование готовых текстур в видеопамять «мгновенное» (по сравнению с 10 секундами конечно), и занимает примерно 1мс на текстуру 512х512 без прозрачности и 2мс для такой же с прозрачностью, если копировать несколько таких текстур друг за другом то время растет нелинейно катастрофически, связано это оказалось с ограниченным объемом буфера видеопамяти, переполнение которого приводило к сбросу буфера и рендеру того что было на экран (велик не мой, он уже там стоял), т.е. для не совсем мертвого интерфейса мы можем копировать не более 50-100 текстур за фрейм и не сразу, а только дождавшись пока видеодрайвер заберет данные из буфера.

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

    Почти победив чудо китайской мысли «без» GPU, все таки нельзя назвать 20 FPS достойным результатом, и почти сдав проект, я попросил у заказчика разрешения забрать часть наработок в опенсорс. Первый SDL сейчас не очень в моде, поэтому было решено использовать рендер nanogui в software режиме на SDL2 и выложить это на гитхабе. Может кому понадобится :)

    Дочитав до конца статью, %хабраюзер% вправе спросить, а зачем было городить эту кучу кода
    ради скругленных уголков и теней? Во первых это красиво (с), во вторых «вон тот дядечка в желтой каске» уже оплатил разработку системы и скругленные уголки там, к сожалению, (или счастью) попали в ТЗ, осталось сделать их с градиентом и добавить немного теней.

    Вот такое было оригинальное лето 2017 года в солнечном Сочи.

    Так выглядит OpenGL рендер



    Так выглядит software рендер на ПК



    Ссылки:

    Оригинальный wjakob/nanogui
    NanoVG software render
    NanoGUI + SDL + software render

    P.S. Не верьте китайцамразработчикам, говорящим о наличие OpenGL в системе, проверяйте работоспособность всех компонентов, знать бы еще как :)
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +2
      Голь на выдумку хитра, зачет )

      P.S. Да читаем мы теги, читаем )
        +6

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

        • НЛО прилетело и опубликовало эту надпись здесь
            0
            И тени и полупрозрачность и блюр и анимации и без ШГ. Все это было и есть на оконных менеджерах, которые не используют видеокарту. Вот совсем. Потому что не нужна вам для этого видеокарта.
            • НЛО прилетело и опубликовало эту надпись здесь
                +1
                xfwm прекрасно себя чувствует на software acceleration без gpu, поддерживает прозрачность и размывание фона без лагов даже на слабом железе. Плюс отображает плавные тени. ПОддержку GPU надо включать USE-флагом или через xorg (обычно сейчас по умолчанию включена, при невозможности схватить контекст он возвращается на софт)

                И встречный вопрос — покажите актуальный юз-кейс *размывания* в интерфейсе пользователя.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Пруфов, конечно же, не будет?
                    Я 4 года просидел на Gentoo не включая hardware acceleration в крысе потому что дрова были отстоем. И мой оконный менеджер прекрасно себя чувствовал и даже полупрозрачность работала.
                    Эм, что значит use case в UI?

                    То и значит. Какое практическое применение имеет размывание в интерфейсе пользователя?
                    В macOS, iOS и Windows 10, например, много где блюр используется
                    Пруфов, конечно же, не будет?
                    Не мало линуксоидов тоже любят красивости. www.reddit.com/r/unixporn тому пример.

                    Просмотрел штук 20 рабочих столов — не увидел применения блюру. Повторю вопрос- зачем вам блюр в интерфейсе пользователя? Интерфейс должен быть четким, чтобы его можно было легко считать и прочитать.
                    • НЛО прилетело и опубликовало эту надпись здесь
                    +2
                    Даже канонические оконные менеджеры 90х годов были весьма чувствительны к отсутствию блиттинга и без него даже тривиальное репозиционирование окна приводило к заметным шлейфам. А это обычно только операции записи в видео-память. Все операции чтения из нее на 1-2 порядка медленнее. Кроме альфа/хрома-ключей (которые классически 2D-акселерируемы) практически все сложные эффекты приводят к большому числу операций чтения. Отсюда у меня большие сомнения в достижимости описываемого без потери в производительности.

                    По моему опыту описываемое достижимо лишь на сравнительно малых объемах перерисовки, особенно на слабом железе. А это либо небольшие окна, либо совсем небольшие разрешения. Нагуглить по Вашему описанию ничего сходу не вышло. Какие-то ссылки/видео имеются по теме?
              +3
              Жизнь — она разная, вероятно будь возможность попробовать систему в реале и увидев такое поведение в начале разработки, мы бы сейчас это не обсуждали :) Но с другой стороны посмотрите на современные SoC, в 90% они содержат гпу, который занимает до половины площади чипа, и не пользоваться им значит лишать себя значительной части доступных ресурсов, забирая их у цпу. А разве рендерить чтото на экран это не прямое назначение гпу, освободив ресурсы для нужных задач? пусть даже это и UI
                +1
                Ресурсов видеокарты вам, значит, жалко, а ресурсов ЦП не жалко. При том, что видеокарта — устройство специализированное, и справляется с задачами отрисовки на порядок лучше.
                  0
                  Видеокарта/ГПУ по определению кушает больше, чем ЦП. И из-за своего потребления требует более развитую систему охлаждения. Всвязи с чем современные ноутбуки начинают троттлить и жрать батарею просто от того, что кто-то решил отрисовать окошко в KDE/Gnome3. Я уже не говорю про встроенные решения.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Может быть проблема не в GPU, а в кривом ноутбуке или ПО?

                      Я и говорю, проблема в ПО, которая для того, чтобы отрисовать обычный гуй без каких-то суперспецэффектов задействует ресурсы такого монстра как гпу. См. habr.com/ru/post/468485/?reply_to=20733044#comment_20732608
                      • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      На отрисовку 2D видеокарта тратит хорошо если 5-10% своих ресурсов. Я вот что-то не помню, чтобы у меня в Win7 видеокарта грелась. А вот ЦП, как видно из статьи, нагружается на 100%.
                      Видеокарта/ГПУ по определению кушает больше, чем ЦП.
                      По какому такому определению? Топовые разве что.
                  +4
                  В 1996 году я делал почти такой интерфейс под Windows 95 на компьютере 486DX, S3 Trio 64V+ 1МБ и ОЗУ (память) 4МБ на Borland C++ 3.1 (без размытия, но оно и не нужно). С появлением GDI+ и alpha-канал стал доступен. А кроме интерфейса и основной функционал был… По-моему, вы делаете что-то не правильно.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Ничего не поменялось
                      0
                      Приятный, а главное тёмный и квадратный гуй. Спасибо, что не стали его скруглять, а то так разочаровывающе в начале написали что у разработчиков интерфейсы «квадратные и скучные».
                        +1

                        Из похожего, есть ещё software renderer for ImGui (и даже оптимизированная версия для embeded'а вроде arduino). Есть даже экспериментальные наработки по remote renderer'у и power save mode.

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

                        Самое читаемое