[Interest] QtQuick2 image rendering and custom shader overhead

Sletta Gunnar Gunnar.Sletta at digia.com
Mon May 6 08:39:06 CEST 2013


On May 5, 2013, at 11:47 AM, Sean Harmer <sean.harmer at kdab.com> wrote:

> On 04/05/2013 19:30, Preet wrote:
>> Hi,

...

>> 
>> 2.
>> I'd like to use ShaderEffects to apply a somewhat trivial shader to most of the images in my application. The images are black and white icons, and I'd like to use shaders to change the black and white output fragments to different colors (ie maybe blue and green, red and yellow, etc). 
>> 
>> The shader itself is super simple and probably adds negligable cost to the pipeline, but I'm concerned about how overall performance would be affected compared to the default method QtQuick uses to render a bunch of images. 
>> 
>> Would QtQuick still intelligently batch the images and draw them using only a few calls? Or would it individually bind the same shader and issue a separate draw call for each image? 
> 
> Using a ShaderEffect item implies rendering the source to a texture via an FBO and then applying the effect's shaders to the resulting texture. Therefore using many ShaderEffects will produce a performance impact at some point. If you really have many of these items to show it would be better to implement a custom item using the scene graph api. Take the existing QSGSimpleTextureNode or image item as starting points and provide a custom material that renders using your colourisation shader.
> 
> This way you avoid the FBO pass for each item.

This is not quite correct :)

Using ShaderEffectSource or "Item.layer: true" does mean going through an FBO. Using ShaderEffect alone or with a plain Image element can be almost the same as using a plain Image element. I say "can" as the content of the shader greatly impacts the resulting performance.

If you do:

Image {
    id: theIcon
    source: "myIcon.png"
    visible: false
}

ShaderEffect {
    propery variant source: theIcon
    width: theIcon.width
    height: theIcon.height

    fragmentShader: "...."
}

There is no FBO involved and the performance will be close to that of rendering a normal Image. Image elements can be used directly as texture sources, you see. In fact any, QQuickItem that implements the QSGTextureProvider interface can be used directly as a texture in a shader effect. It is also possible to use ShaderEffect without textures, for instance to render a gradient.

As for batching, our current defualt renderer does not do that, it only reorders rendering commands to minimise state changes and to use the depth buffer to cull elements behind opaque elements. 

cheers,
Gunnar

> 
> Hope this helps,
> 
> Sean
> 
>> 
>> 
>> Preet
>> 
>> -- 
>> This message has been scanned for viruses and 
>> dangerous content by MailScanner, and is 
>> believed to be clean. 
>> 
>> _______________________________________________
>> Interest mailing list
>> 
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> -- 
> Dr Sean Harmer | 
> sean.harmer at kdab.com
>  | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest




More information about the Interest mailing list