Re: [Interest] Faster way of rendering QOpenGLFramebufferObject to image
Elvis,
Using your quick example (attached as a project below) I’ve run some tests and
realised that window rendering it not happening at the same frame rate in all
machines and the maximum differs:
- no more than 30 fps in on a 2017 iMac with Radeon graphics card
- no more than 30 fps on 2019 Intel Mac Book with Intel Graphics
- up to 144 fps on a Windows machine with an RTX 2060
- 115 fps on a 2018 12.9” iPad Pro
Changing the width and height of the scene doesn’t seem to impact the frame
rate.
I was expecting to have more than 60 fps on the iMac and Macbook. I don’t think
this simple scene would be limited to 30 fps
At this point, I’m not taking into consideration that time it takes to obtain
the pixel data from the fbo/texture.
Since in order to have v-sync with window when painting the context of the
texture rendered on the offscreen renderer I need to drive the paint via main
window paint, this means that I will be limited by main window painting frame
rate.
Is anyone aware of frame rate limitations of a qquickwindow painting?
Project attached.
Thanks,
Best regards,
Nuno
<>
> On 14 Jul 2021, at 23:48, Elvis Stansvik wrote:
>
> My idea would be something like (sketch):
>
> main.cpp:
>
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> QGuiApplication app(argc, argv);
>
> auto view = new QQuickView;
> view->setSource(QUrl::fromLocalFile("test.qml"));
> view->show();
>
> // I use a QVector here, but you would have your AVFrame and
> // its allocated memory buffer..
> QVector buffer;
> QMutex mutex;
>
> QObject::connect(view, &QQuickView::afterRendering, view, [&]() {
> mutex.lock();
> buffer.resize(4 * view->width() * view->height());
> glReadPixels(0, 0, view->width(), view->height(), GL_RGBA,
> GL_UNSIGNED_BYTE, buffer.data());
> mutex.unlock();
> }, Qt::DirectConnection);
>
> return app.exec();
> }
>
> test.qml:
>
> import QtQuick 2.2
>
> Rectangle {
> width: 1920
> height: 1080
>
> Rectangle {
> width: 500
> height: 500
> color: "green"
> anchors.centerIn: parent
> RotationAnimation on rotation {
> from: 0
> to: 360
> duration: 2000
> loops: Animation.Infinite
> }
> }
> }
>
> I don't know whether this would work for you.
>
> Elvis
>
> Den tis 13 juli 2021 kl 15:31 skrev Nuno Santos :
>>
>> Elvis,
>>
>> Thanks for sharing your thoughts. It makes sense.
>>
>> I need to dive into the toImage function, try to read directly the bytes
>> from the FBO and see if that has any performance impact.
>>
>> Best regards,
>>
>> Nuno
>>
>>> On 13 Jul 2021, at 14:10, Elvis Stansvik wrote:
>>>
>>> Hi Nuno,
>>>
>>> I'm really out of my waters here, but, provided you don't need to hold
>>> on to each AVFrame after you are "done with it", you could perhaps
>>> avoid having to allocate a QImage for each frame (which toImage forces
>>> you to do) by just allocating a a single AVFrame and a single memory
>>> buffer for it, and then do what toImage does, which is make sure the
>>> FBO is bound and read the pixels off of it with glReadPixels. Then you
>>> could read the pixels straight into the memory buffer used by your
>>> AVFrame.
>>>
>>> That way you would save the overhead of a new QImage being allocated
>>> each time, which might speed things up..?
>>>
>>> Just ideas here. Have not worked with GL or ffmpeg before.
>>>
>>> Elvis
>>>
>>> Den tis 13 juli 2021 kl 11:22 skrev Nuno Santos :
Hi,
I’m trying to capture the content of an FBO to a video file. This video
file should contain the animations generated by a qml scene.
To do this, I’m recurring to QOpenGLFramebufferObject class toImage()
method.
My scene is being drawn at 1920x1080. Each call to toImage takes 30 ms! :(
If I want to render to file at 60 fps, ideally, this call would need to
take less than 16 ms to give me room to do other operations, such as video
encoding and the actual render.
As anyone been here before? What other strategies are available to copy
the FBO data to an image?
I’m using libav to encode the video file, therefor I need to fill an
AVFrame. Right now I’m filling the AVFrame from the QImage generated by
the FBO toImage method.
Does any one knows a method of filling an AVFrame directly from texture
data?
Thanks
Best regards,
Nuno
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
>>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Qt Creator: target SDK versions are grayed out?
Hello, Why can't I choose target sdk versions here? It's a new project. All I did is created templates using the appropriate Qt Creator button. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator: target SDK versions are grayed out?
Am 15.07.21 um 12:44 schrieb Alexander Dyagilev: Hello, Why can't I choose target sdk versions here? It's a new project. All I did is created templates using the appropriate Qt Creator button. this is because Min and Target SDK isn't part of Android Manifest anymore - it's now part of Gradle.properties you have to set this in .pro, per ex.: ANDROID_MIN_SDK_VERSION="21" ANDROID_TARGET_SDK_VERSION="29" then it will be auto-magically set into Gradle.properties - you can verify this from your shadow build ekke ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator: target SDK versions are grayed out?
Thanks. On 7/15/2021 2:05 PM, ekke wrote: Am 15.07.21 um 12:44 schrieb Alexander Dyagilev: Hello, Why can't I choose target sdk versions here? It's a new project. All I did is created templates using the appropriate Qt Creator button. this is because Min and Target SDK isn't part of Android Manifest anymore - it's now part of Gradle.properties you have to set this in .pro, per ex.: ANDROID_MIN_SDK_VERSION="21" ANDROID_TARGET_SDK_VERSION="29" then it will be auto-magically set into Gradle.properties - you can verify this from your shadow build ekke ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Android AAB and shared libs?
Hello, In my project I have 2 sub projects: application and shared library, which application uses. Shared library: TARGET = logger TEMPLATE = lib CONFIG += qt skip_target_version_ext DESTDIR = ../../../bin Application: LIBS *= -L$$OUT_PWD/$$DESTDIR -llogger All was working fine before AAB. Now I'm trying to compile using Qt 5.15.2 + AAB. It generates the following error: error: cannot find -llogger This is because its name now is liblogger_armeabi-v7a.so. Is there a simple way to fix this? I also need this to still be able to build with Qt 5.12.11 APK format. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Android AAB and shared libs?
perhaps this helps to understand aab builds ? https://www.kdab.com/qt-for-android-better-than-ever-before/ ekke Am 15.07.21 um 13:11 schrieb Alexander Dyagilev: Hello, In my project I have 2 sub projects: application and shared library, which application uses. Shared library: TARGET = logger TEMPLATE = lib CONFIG += qt skip_target_version_ext DESTDIR = ../../../bin Application: LIBS *= -L$$OUT_PWD/$$DESTDIR -llogger All was working fine before AAB. Now I'm trying to compile using Qt 5.15.2 + AAB. It generates the following error: error: cannot find -llogger This is because its name now is liblogger_armeabi-v7a.so. Is there a simple way to fix this? I also need this to still be able to build with Qt 5.12.11 APK format. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Faster way of rendering QOpenGLFramebufferObject to image
Den tors 15 juli 2021 kl 10:30 skrev Nuno Santos :
>
> Elvis,
>
> Using your quick example (attached as a project below) I’ve run some tests
> and realised that window rendering it not happening at the same frame rate in
> all machines and the maximum differs:
>
> - no more than 30 fps in on a 2017 iMac with Radeon graphics card
> - no more than 30 fps on 2019 Intel Mac Book with Intel Graphics
> - up to 144 fps on a Windows machine with an RTX 2060
> - 115 fps on a 2018 12.9” iPad Pro
>
> Changing the width and height of the scene doesn’t seem to impact the frame
> rate.
>
> I was expecting to have more than 60 fps on the iMac and Macbook. I don’t
> think this simple scene would be limited to 30 fps
It does sound like a bug to me, unless somehow those Mac systems are
running at a 30 Hz monitor refresh rate and Quick is trying to match
that, but it seems very unlikely.
Unless someone here knows, I'd file a bug with a minimal example.
I did try adding some basic timing to my earlier example, and on my
Linux laptop afterRendering is called at a rate of 60 Hz.
Elvis
>
> At this point, I’m not taking into consideration that time it takes to obtain
> the pixel data from the fbo/texture.
>
> Since in order to have v-sync with window when painting the context of the
> texture rendered on the offscreen renderer I need to drive the paint via main
> window paint, this means that I will be limited by main window painting frame
> rate.
>
> Is anyone aware of frame rate limitations of a qquickwindow painting?
>
> Project attached.
>
> Thanks,
>
> Best regards,
>
> Nuno
>
>
>
> > On 14 Jul 2021, at 23:48, Elvis Stansvik wrote:
> >
> > My idea would be something like (sketch):
> >
> > main.cpp:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > int main(int argc, char *argv[])
> > {
> > QGuiApplication app(argc, argv);
> >
> > auto view = new QQuickView;
> > view->setSource(QUrl::fromLocalFile("test.qml"));
> > view->show();
> >
> > // I use a QVector here, but you would have your AVFrame and
> > // its allocated memory buffer..
> > QVector buffer;
> > QMutex mutex;
> >
> > QObject::connect(view, &QQuickView::afterRendering, view, [&]() {
> > mutex.lock();
> > buffer.resize(4 * view->width() * view->height());
> > glReadPixels(0, 0, view->width(), view->height(), GL_RGBA,
> > GL_UNSIGNED_BYTE, buffer.data());
> > mutex.unlock();
> > }, Qt::DirectConnection);
> >
> > return app.exec();
> > }
> >
> > test.qml:
> >
> > import QtQuick 2.2
> >
> > Rectangle {
> > width: 1920
> > height: 1080
> >
> > Rectangle {
> > width: 500
> > height: 500
> > color: "green"
> > anchors.centerIn: parent
> > RotationAnimation on rotation {
> > from: 0
> > to: 360
> > duration: 2000
> > loops: Animation.Infinite
> > }
> > }
> > }
> >
> > I don't know whether this would work for you.
> >
> > Elvis
> >
> > Den tis 13 juli 2021 kl 15:31 skrev Nuno Santos :
> >>
> >> Elvis,
> >>
> >> Thanks for sharing your thoughts. It makes sense.
> >>
> >> I need to dive into the toImage function, try to read directly the bytes
> >> from the FBO and see if that has any performance impact.
> >>
> >> Best regards,
> >>
> >> Nuno
> >>
> >>> On 13 Jul 2021, at 14:10, Elvis Stansvik wrote:
> >>>
> >>> Hi Nuno,
> >>>
> >>> I'm really out of my waters here, but, provided you don't need to hold
> >>> on to each AVFrame after you are "done with it", you could perhaps
> >>> avoid having to allocate a QImage for each frame (which toImage forces
> >>> you to do) by just allocating a a single AVFrame and a single memory
> >>> buffer for it, and then do what toImage does, which is make sure the
> >>> FBO is bound and read the pixels off of it with glReadPixels. Then you
> >>> could read the pixels straight into the memory buffer used by your
> >>> AVFrame.
> >>>
> >>> That way you would save the overhead of a new QImage being allocated
> >>> each time, which might speed things up..?
> >>>
> >>> Just ideas here. Have not worked with GL or ffmpeg before.
> >>>
> >>> Elvis
> >>>
> >>> Den tis 13 juli 2021 kl 11:22 skrev Nuno Santos
> >>> :
>
> Hi,
>
> I’m trying to capture the content of an FBO to a video file. This video
> file should contain the animations generated by a qml scene.
>
> To do this, I’m recurring to QOpenGLFramebufferObject class toImage()
> method.
>
> My scene is being drawn at 1920x1080. Each call to toImage takes 30 ms!
> :(
>
> If I want to render to file at 60 fps, ideally, this call would need to
> take less than 16 ms to give me room to do other operations, such as
> video encoding and the actual render.
>
> As anyone been here before? What other strategies are available to copy
> the FBO data to an image?
>
> I’m using libav to encode the video file, therefor I need to fil
