Комментарии 12
Поясните пожалуйста, чем обусловлена цифра 5 в renderTimer->setInterval( 5 );
0
Если быть честным — я не знаю точного ответа на данный вопрос. Число было взято из примера rendercontrol (window.cpp:100).
Я предполагаю что при выборе данного интервала стоит ориентироваться на желатемый fps. Но лучше, как мне кажется, вовсе не использовать таймер, а привязываться вертикальной синхронизаци (VSync) экрана.
Я предполагаю что при выборе данного интервала стоит ориентироваться на желатемый fps. Но лучше, как мне кажется, вовсе не использовать таймер, а привязываться вертикальной синхронизаци (VSync) экрана.
0
Желаемый fps для вас — 200?
Да, вы правы, лучше не использовать таймер, хотелось бы и увидеть привязку к вертикальной синхронизации.
Да, вы правы, лучше не использовать таймер, хотелось бы и увидеть привязку к вертикальной синхронизации.
0
скорее не для меня а для автора rendercontrol :)
0
Скорее даже не понятно, почему сигналы не вызываются в момент когда действительно должна произойти отрисовка, и не пихают примитивы в контекст, а вместо этого нужно делать отдельный «пререндеринг» текстуры, которая в последствии будет отдана на отрисовку.
0
Я думаю что это может быть связано с тем фактом что при стандартном использовании QQuickWindow (т.е. без использования QQuickRenderControl) рендеринг осуществляется в отдельной нити (согласно документации и личного опыта).
Кроме того, заранее сложно предположить как и где в дальнейшем пользователь будет использовать полученный FBO — как следствие необходимо предоставлять максимальные возможности, даже ценой усложнения использования.
Кроме того, заранее сложно предположить как и где в дальнейшем пользователь будет использовать полученный FBO — как следствие необходимо предоставлять максимальные возможности, даже ценой усложнения использования.
0
Тут идет не только усложнение использования, но сильная потеря производительности. Я уже смотрел как происходит рендеринг при «стандартном использовании QQuickWindow», я просто не очень понял почему нельзя было сделать тот же механизм, со «сбросом» SGNode'ов, но в чужом контексте. Единственная адекватная причина — отсутствие «синхронных» нотификаций о входе в функцию рисования. Хотя с другой стороны не понятно как тогда работает сброс FBO. В общем надо смотреть имплементацию QQuickWindow и околостоящих классов при работе с «чужим» контекстом. Если у Вас будет желание и возможность, то было бы круто увидеть это в «Продолжение следует...» :)
0
Я думаю что это просто напросто первая итерация реализации идеи, причем реализованная «на скорую руку» — Предполагаю что в одной из следующих версий мы увидим полностью переработанную концепцию — уж больно много «вкусностей» обещает данный подход.
0
а по поводу «Продолжение следует...» — я бы рад, осталось только придумать как увеличить количество часов в сутках хотя бы до 26-ти ;)
+1
Скажите, а как вы узнаете когда должна произойти отрисовка?
0
За статью спасибо, в целом это выглядит очень печально. Появилось желание посмотреть как это работает внутри, потому что костыль(Со стороны Qt) какой-то уж больно топорный…
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QQuickRenderControl, или как подружить QML с чужим OpenGL контекстом. Часть I