Исправление pon4ik, (текущая версия) :
Ну смотри, человеческий глаз, скажем геймерский различает люфт в миллисекунду (учитывая тёрки про кино, и про 25ый кадр, эта цифра сильно занижена). Остальное тело ещё медленнее.
Но, если раз в эту условную миллисекунду не обработать действие пользователя или не перерисовать изменившуюся картинку, будет заметно то, что в простанородье именуют «лаг».
Поэтому типовой gui поток (Qt тут 100% не исключение в их эвент луп я сравнительно недавно лазил в 5.6 версию вроде) - после обработки очередного колбэка (или 10 колбэков например), засыпает до наступления события от пользователя или истечения таймаута.
Отсюда, gui поток по определению проводит очень много времени во сне/обработке io, если не давать ему спать ui будет «тормозить».
Это я всё подвожу товарища TC, к мысли о том, что ни о каких гигантских потоках данных, распаковка/запаковка которых будет жечь проц на пропалую, речь идти не может, в силу того, что устройство ввода вывода не просто медленнее чем процессор, оно ещё и медленнее чем практически любое ipc (если не брать экзотические для такого сценария вещи типа Bluetooth или gpio или медленных сетевых соединений).
Другой вопрос, что в выбранным им подходе, ему придётся реализовать интерфейс mvc на rpc api, т.е. в случае Qt, повторить интерфейс QAbstractItemModel, ну и можно ещё обмазать всё это кэшированием.
Исходная версия pon4ik, :
Ну смотри, человеческий глаз, скажем геймерский различает люфт в миллисекунду (учитывая тёрки про кино, и про 25ый кадр, эта цифра сильно занижена). Остальное тело ещё медленнее.
Но, если раз в эту условную миллисекунду не обработать действие пользователя или не перерисовать изменившуюся картинку, будет заметно то, что в простанородье именуют «лаг».
Поэтому типовой gui поток (Qt тут 100% не исключение в их эвент луп я сравнительно недавно лазил в 5.6 версию вроде) - после обработки очередного колбэка (или 10 колбэков например), засыпает до наступления события от пользователя или истечения таймаута.
Отсюда, gui поток по определению проводит очень много времени во сне, если не давать ему спать ui будет «тормозить».
Это я всё подвожу товарища TC, к мысли о том, что ни о каких гигантских потоках данных, распаковка/запаковка которых будет жечь проц на пропалую, речь идти не может, в силу того, что устройство ввода вывода не просто медленнее чем процессор, оно ещё и медленнее чем практически любое ipc (если не брать экзотические для такого сценария вещи типа Bluetooth или gpio или медленных сетевых соединений).
Другой вопрос, что в выбранным им подходе, ему придётся реализовать интерфейс mvc на rpc api, т.е. в случае Qt, повторить интерфейс QAbstractItemModel, ну и можно ещё обмазать всё это кэшированием.