Ну, какую-нибудь диаграммку, например, нарисовать. Из блоков и связей. Например, из 100к блоков 100к связей. И блоки какие-нибудь не простые, а с текстом, заголовками, входами/выходами. Если перевести в полигоны - для OpenGL это семечки. Современные 3D модельки содержат на порядки больше геометрии. Но вот если это описывать через QQuickItem'ы.... Так что тут или glBegin и вперед низкоуровневые draw call'ы, или чего-нибудь другое. Смешно, что QGraphicsScene, будучи полностью software rendered, такое вывозит без труда. Но его напрямую вывести в QtQuick нельзя. Нужен вьюпорт (прямоугольник, ездящий по диаграмме - какую часть рисовать). А Flickable подсунуть Image - не выйдет. Растеризовать-то надо только часть. В общем, есть сложности стыковки.
По факту оно предлагает существенное падение производительности :) Очень специфическое у кого-то в QT представление о параллелелизме. Выполняем поток, планируем вызов функции в другом потоке, а потом ждем в 1м пока второй поток не выполнит функцию. Это медленнее хотя бы за счет необходимости переключения контекста потока и синхронизации туда-сюда-обратно. Я бы еще понял, если бы scene graph рендерился параллельно в несколько потоков, или если бы GUI поток продолжал бы выполнение в процессе отрисовки, т.е. следующий кадр готовился бы, пока рисуется текущий. Но по факту ничего такого нет, это просто пыль в глаза. Типа вот, смотрите - у нас многопоточность!
Есть QWindow::showFullScreen и он врубает настоящий полноэкранный режим. И он так же врубается автоматом, если у окна отключить рамку и задать геометрию под экран. В этом режиме попытки показать поверх полноэкранного приложения другие окна выглядят так себе. Все мерцает, появляется/пропадает. В общем такое. Попробуйте запустить старую полноэкранную игру, а потом поверх неё вытащить другое окно. Поэтому сейчас в моде borderless full screen (просто top level окно с геометрией на весь экран).
Грузить UI поток перекачкой семпл-буферов не хотелось. Сигналы - лишние события и задержки. UI высоконагруженный, не хотелось, что бы воспроизведение аудио заикалось до окончания декодирования. Оно работает нормально, только нельзя уничтожать QAudioDecoder. Утечки QMediaPlayer - в 5.9 оно точно есть, а дальше не знаю. Это, конечно, относительно давно, только вот обновить версию QT для большого приложения занятие не из простых. Нужно выделять время на обкатку новых багов.
Переставало рендерится после показа модального диалога, для которого у окна была включена прозрачность. А у основного окна не была. Оставался последний нарисованный кадр в окне, который стирался белым при утаскивании окна за границу экрана. При этом внятно юзеры сформулировать причину "зависания" не смогли. Типа что-то сделали и оно перестало обновлять окно. При этом всплывало только на Linux. Виндузовый opengl32.dll такое прощает.
Никогда не забуду, как я неделю искал причину "зависания" UI в QtQuick приложении. Как оказалось, из-за вызова g_source_remove (отключает обработку системных message в главном message loop) вместо g_source_destroy из ~QGstreamerBusHelperPrivate, по тому, что я имел глупость использовать QAudioDecoder в фоновом потоке (API-то вроде как синхронное, хотя из доков сложно понять). А QAudioDecoder пришлось использовать для самодельного вывода звука через QAudioOutput, по тому, что циклический вывод коротких звуков через QMediaPlayer вызывал серьезные утечки памяти с gstreamer бекендом.
Это был второй по веселости баг, после 2х недель отладки другого трудноуловимого "повисания" приложения. Как выяснилось, из-за несовместимых форматов поверхностей и OpenGL'контекста. Ну правильно, проверять код возврата glMakeCurrent - это не по нашему. Не вышло - ну и хрен с ним. Сам же программист дурак, да? Не нашел в справке по QQuickWindow описание метода setDefaultAlphaBuffer? На! RTFM!
Оххх, а сколько было веселья с переключением в полноэкранный режим. Особо умные разработчики решили, что это хорошая идея автоматом врубать "истинный" полноэкранный режим OpenGL когда геометрия клиентской части окна совпадает с геометрией экрана. Такие мелочи как контекстные меню и подсказки (которых из коробки не было и пришлось сделать самому), т.е. всплывающие окна поверх полноэкрана - разрабов не озаботили. А выглядит оно так себе. Поэтому сейчас используется элегантное решение с выезжанием окна на 1 пиксель за границы экрана, что бы случайно не включился полноэкранный режим. Такой borderless full screen по Qt-шному.
Но это под Win. А под X11 у нас ведь xinerama, и если надо на несколько мониторов - это уже через XSendEvent с _NET_WM_FULLSCREEN_MONITORS. Ой, но ведь оно не всеми оконными менеджерами поддерживается, так что еще надо смотреть на XDG_CURRENT_DESKTOP. Даа, кроссплатформа что надо.
Ох, а как земечательно сделан "многопоточный рендеринг" (QSG_RENDER_LOOP=threaded). Который на самом деле просто тормозит GUI поток и ждет пока там отрисует фоновый. Что по факту просто медленнее чем нарисовать кадр синхронно из GUI потока... Ух, а если еще в приложении несколько окон...
А производительность рендеринга на больших scenegraph? Хочешь 100500 QQuickItem с автоматической обрезкой геометрии? Неее, это тебе надо QGraphicsScene. Там тебе и BSP-дерево, и растровое кеширование, и шрифты без глюков на масштабе, отличном от 1:1 (ох уж этот distance field). Но вот проблемка - оно же для QPainter... Ну ничего есть же QSGSimpleTextureNode, дальше пользователи платформы как-нить сообразят.
А глюк c разваливающимся деревом...
В общем, если бы у меня были злейшие враги, я бы от души пожелал им стать первоклассными разработчиками кроссплатформенных Desktop приложений на C++/Qt.
Да, точно, я и забыл :) Сижу себе на 1080 и не парюсь. Хотя разница при работе за монитором имеется, хоть и не такая уж огромная. С другой стороны, я не испытываю моральные страдания от разницы в качестве картинки при работе в офисе :) Ноут… ну такое, с 2/3 мониторами не очень удобно.
Авита без вопросов скоро будет завалена предложениями от перекупов. По другому просто быть не может. Я б за 300 баксов у китайцев 3070 взял бы… хотя нет. Играть-то не во что. Все что есть, прекрасно идет на 1060. А вот акции NVidia пора продавать.
Интересно интересно. Как это оно влезает в стек ренрединга шрифтов. Зная Microsoft — скорее всего оно закопано где-нибудь глубоко. Да и такой зоопарк API рендеринга текста… GDI, GDI+, Milcore (WPF, там свой стек), DirectX, OpenGL. В QT Quick в режиме Ideal по моему используется Harfbuzz с какими-то своими алгоритмами сглаживания.
Ну я с лупой не сравнивал, просто установил шрифт в систему и выбрал его в качестве шрифта в настройках Tools\Options\Environment\Fonts and colors\TextEditor. Если это Courier New — значит студия вообще отказалась использовать JetBrains Mono.
Update. Нет, пробую переключать с JetBrains Mono на Courier New — отображение всё таки несколько меняется.
В VS 2019 как-то не очень. Вообще она странно его показывает, не похоже на то, что на картинках. JetBrains Mono (слева) vs. Droid Sans Mono Slashed (справа):
Безумие. Фото и образец голоса станут ключами от королевства?
Ну фото — это вообще без комментариев — надо значит срочно удалять себя из всех соц. сетей и вообще.
Голос. А как будет происходить сопоставление с эталоном? Четкого совпадения-то никогда не будет. Кроме того — частота дискретизации, качество микрофона и еще миллион параметров. Т.е. даже качественное аудио — это информация с очень низким «разрешением». Значит можно будет забрутфорсить систему.
Ну и к этому можно добавить существенные успехи в технологиях генерации изображений и аудио с использованием нейросетей.
Т.е. больше варантов идентификации по ИЛИ = больше вариантов кражи денег. Вот если бы по И — тогда да, тогда я бы еще согласился. Введи пароль, пришли фото, скажи фразу в микрофон — тогда может и пустим. Но по ИЛИ — безумие. А на сколько я понял — предлагается внедрить именно этот вариант.
Может быть, может быть, я так глубоко в отладчике не закапывался. Но штука неприятная.
TreeView в QtQuickControls 1.0 - такое себе.
Ну, какую-нибудь диаграммку, например, нарисовать. Из блоков и связей. Например, из 100к блоков 100к связей. И блоки какие-нибудь не простые, а с текстом, заголовками, входами/выходами. Если перевести в полигоны - для OpenGL это семечки. Современные 3D модельки содержат на порядки больше геометрии. Но вот если это описывать через QQuickItem'ы.... Так что тут или glBegin и вперед низкоуровневые draw call'ы, или чего-нибудь другое. Смешно, что QGraphicsScene, будучи полностью software rendered, такое вывозит без труда. Но его напрямую вывести в QtQuick нельзя. Нужен вьюпорт (прямоугольник, ездящий по диаграмме - какую часть рисовать). А Flickable подсунуть Image - не выйдет. Растеризовать-то надо только часть. В общем, есть сложности стыковки.
По факту оно предлагает существенное падение производительности :) Очень специфическое у кого-то в QT представление о параллелелизме. Выполняем поток, планируем вызов функции в другом потоке, а потом ждем в 1м пока второй поток не выполнит функцию. Это медленнее хотя бы за счет необходимости переключения контекста потока и синхронизации туда-сюда-обратно. Я бы еще понял, если бы scene graph рендерился параллельно в несколько потоков, или если бы GUI поток продолжал бы выполнение в процессе отрисовки, т.е. следующий кадр готовился бы, пока рисуется текущий. Но по факту ничего такого нет, это просто пыль в глаза. Типа вот, смотрите - у нас многопоточность!
Есть QWindow::showFullScreen и он врубает настоящий полноэкранный режим. И он так же врубается автоматом, если у окна отключить рамку и задать геометрию под экран. В этом режиме попытки показать поверх полноэкранного приложения другие окна выглядят так себе. Все мерцает, появляется/пропадает. В общем такое. Попробуйте запустить старую полноэкранную игру, а потом поверх неё вытащить другое окно. Поэтому сейчас в моде borderless full screen (просто top level окно с геометрией на весь экран).
Грузить UI поток перекачкой семпл-буферов не хотелось. Сигналы - лишние события и задержки. UI высоконагруженный, не хотелось, что бы воспроизведение аудио заикалось до окончания декодирования. Оно работает нормально, только нельзя уничтожать QAudioDecoder. Утечки QMediaPlayer - в 5.9 оно точно есть, а дальше не знаю. Это, конечно, относительно давно, только вот обновить версию QT для большого приложения занятие не из простых. Нужно выделять время на обкатку новых багов.
Переставало рендерится после показа модального диалога, для которого у окна была включена прозрачность. А у основного окна не была. Оставался последний нарисованный кадр в окне, который стирался белым при утаскивании окна за границу экрана. При этом внятно юзеры сформулировать причину "зависания" не смогли. Типа что-то сделали и оно перестало обновлять окно. При этом всплывало только на Linux. Виндузовый opengl32.dll такое прощает.
Никогда не забуду, как я неделю искал причину "зависания" UI в QtQuick приложении. Как оказалось, из-за вызова g_source_remove (отключает обработку системных message в главном message loop) вместо g_source_destroy из ~QGstreamerBusHelperPrivate, по тому, что я имел глупость использовать QAudioDecoder в фоновом потоке (API-то вроде как синхронное, хотя из доков сложно понять). А QAudioDecoder пришлось использовать для самодельного вывода звука через QAudioOutput, по тому, что циклический вывод коротких звуков через QMediaPlayer вызывал серьезные утечки памяти с gstreamer бекендом.
Это был второй по веселости баг, после 2х недель отладки другого трудноуловимого "повисания" приложения. Как выяснилось, из-за несовместимых форматов поверхностей и OpenGL'контекста. Ну правильно, проверять код возврата glMakeCurrent - это не по нашему. Не вышло - ну и хрен с ним. Сам же программист дурак, да? Не нашел в справке по QQuickWindow описание метода setDefaultAlphaBuffer? На! RTFM!
Оххх, а сколько было веселья с переключением в полноэкранный режим. Особо умные разработчики решили, что это хорошая идея автоматом врубать "истинный" полноэкранный режим OpenGL когда геометрия клиентской части окна совпадает с геометрией экрана. Такие мелочи как контекстные меню и подсказки (которых из коробки не было и пришлось сделать самому), т.е. всплывающие окна поверх полноэкрана - разрабов не озаботили. А выглядит оно так себе. Поэтому сейчас используется элегантное решение с выезжанием окна на 1 пиксель за границы экрана, что бы случайно не включился полноэкранный режим. Такой borderless full screen по Qt-шному.
Но это под Win. А под X11 у нас ведь xinerama, и если надо на несколько мониторов - это уже через XSendEvent с _NET_WM_FULLSCREEN_MONITORS. Ой, но ведь оно не всеми оконными менеджерами поддерживается, так что еще надо смотреть на XDG_CURRENT_DESKTOP. Даа, кроссплатформа что надо.
Ох, а как земечательно сделан "многопоточный рендеринг" (QSG_RENDER_LOOP=threaded). Который на самом деле просто тормозит GUI поток и ждет пока там отрисует фоновый. Что по факту просто медленнее чем нарисовать кадр синхронно из GUI потока... Ух, а если еще в приложении несколько окон...
А производительность рендеринга на больших scenegraph? Хочешь 100500 QQuickItem с автоматической обрезкой геометрии? Неее, это тебе надо QGraphicsScene. Там тебе и BSP-дерево, и растровое кеширование, и шрифты без глюков на масштабе, отличном от 1:1 (ох уж этот distance field). Но вот проблемка - оно же для QPainter... Ну ничего есть же QSGSimpleTextureNode, дальше пользователи платформы как-нить сообразят.
А глюк c разваливающимся деревом...
В общем, если бы у меня были злейшие враги, я бы от души пожелал им стать первоклассными разработчиками кроссплатформенных Desktop приложений на C++/Qt.
С моего кухонного стола :)
P.S. Добавить картинку в спойлере это нынче квест почище старого.
Описание конечно эпичное. Первый раз слышу. Что оно вообще делает?
Update. Нет, пробую переключать с JetBrains Mono на Courier New — отображение всё таки несколько меняется.
Ну фото — это вообще без комментариев — надо значит срочно удалять себя из всех соц. сетей и вообще.
Голос. А как будет происходить сопоставление с эталоном? Четкого совпадения-то никогда не будет. Кроме того — частота дискретизации, качество микрофона и еще миллион параметров. Т.е. даже качественное аудио — это информация с очень низким «разрешением». Значит можно будет забрутфорсить систему.
Ну и к этому можно добавить существенные успехи в технологиях генерации изображений и аудио с использованием нейросетей.
Т.е. больше варантов идентификации по ИЛИ = больше вариантов кражи денег. Вот если бы по И — тогда да, тогда я бы еще согласился. Введи пароль, пришли фото, скажи фразу в микрофон — тогда может и пустим. Но по ИЛИ — безумие. А на сколько я понял — предлагается внедрить именно этот вариант.