Discussion:
How to render small Images decently on non retina displays with QtQuick?
(too old to reply)
Nuno Santos
2018-03-06 15:27:01 UTC
Permalink
Hi,

I have a simple question.

How to render small Images decently on non retina displays with QtQuick?

In my apps, I use images for icons and logos. They are all big enough to be displayed correctly.

However, on non Retina displays they get really bad! And on retine display they appear perfectly.

What is the rule of thumb to use QtQuick Image element on on retina displays?

Thx!

Regards,

Nuno
Mitch Curtis
2018-03-06 15:41:53 UTC
Permalink
Can you elaborate on "really bad", and also share a screenshot?

From: Interest [mailto:interest-bounces+mitch.curtis=***@qt-project.org] On Behalf Of Nuno Santos
Sent: Tuesday, 6 March 2018 4:27 PM
To: Qt Project MailingList <***@qt-project.org>
Subject: [Interest] How to render small Images decently on non retina displays with QtQuick?

Hi,

I have a simple question.

How to render small Images decently on non retina displays with QtQuick?

In my apps, I use images for icons and logos. They are all big enough to be displayed correctly.

However, on non Retina displays they get really bad! And on retine display they appear perfectly.

What is the rule of thumb to use QtQuick Image element on on retina displays?

Thx!

Regards,

Nuno
Nuno Santos
2018-03-06 15:50:23 UTC
Permalink
Mitch,

Thanks for your reply.

You are right. I’m not playing all the cards


Original image attached (it is white over transparent so you will not see it in the email body. The file is called isotope.png)

The item who renders this is the following:

import QtQuick 2.4

Item {
id: root
implicitWidth: 100
implicitHeight: 100

property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor

Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}

ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
Can you elaborate on “really bad”, and also share a screenshot?
Sent: Tuesday, 6 March 2018 4:27 PM
Subject: [Interest] How to render small Images decently on non retina displays with QtQuick?
Hi,
I have a simple question.
How to render small Images decently on non retina displays with QtQuick?
In my apps, I use images for icons and logos. They are all big enough to be displayed correctly.
However, on non Retina displays they get really bad! And on retine display they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
Jason H
2018-03-06 16:06:30 UTC
Permalink
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Xavier Bigand
2018-03-06 16:45:05 UTC
Permalink
Hi,

If your sample picture is relevant I can suggest you to convert it as SVG
(vectoring it) or using distance field technique.
Maybe this has something to do with with mipMapping/smooth? It looks like
it's not anti-aliasing?
*Sent:* Tuesday, March 06, 2018 at 10:50 AM
*Subject:* Re: [Interest] How to render small Images decently on non
retina displays with QtQuick?
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not see
it in the email body. The file is called isotope.png)
import QtQuick 2.4
Item {
id: root
implicitWidth: 100
implicitHeight: 100
property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor
Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}
ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
Can you elaborate on “really bad”, and also share a screenshot?
Santos
*Sent:* Tuesday, 6 March 2018 4:27 PM
*Subject:* [Interest] How to render small Images decently on non retina
displays with QtQuick?
Hi,
I have a simple question.
*How to render small Images decently on non retina displays with QtQuick?*
In my apps, I use images for icons and logos. They are all big enough to
be displayed correctly.
However, on non Retina displays they get really bad! And on retine display
they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________ Interest mailing list
mailman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Xavier
Nuno Santos
2018-03-06 16:47:17 UTC
Permalink
I have never used SVG in QtQuick.

What can be used to render SVG’s in QtQuick?
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG (vectoring it) or using distance field technique.
Maybe this has something to do with with mipMapping/smooth? It looks like it's not anti-aliasing?
Sent: Tuesday, March 06, 2018 at 10:50 AM
Subject: Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not see it in the email body. The file is called isotope.png)
import QtQuick 2.4
Item {
id: root
implicitWidth: 100
implicitHeight: 100
property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor
Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}
ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
<Mail Attachment.png><Mail Attachment.png>
<Mail Attachment.png>
Can you elaborate on “really bad”, and also share a screenshot?
Sent: Tuesday, 6 March 2018 4:27 PM
Subject: [Interest] How to render small Images decently on non retina displays with QtQuick?
Hi,
I have a simple question.
How to render small Images decently on non retina displays with QtQuick?
In my apps, I use images for icons and logos. They are all big enough to be displayed correctly.
However, on non Retina displays they get really bad! And on retine display they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest <http://lists.qt-project.org/mailman/listinfo/interest>
--
Xavier
Xavier Bigand
2018-03-06 16:50:00 UTC
Permalink
I think that you just have to link the svg module, if I remember correctly,
then in QML just use it as source of an Image item.
The only think is that you have to fix the size of the item as the
sourceSize have no sense here.
Post by Nuno Santos
I have never used SVG in QtQuick.
What can be used to render SVG’s in QtQuick?
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG
(vectoring it) or using distance field technique.
Maybe this has something to do with with mipMapping/smooth? It looks like
it's not anti-aliasing?
*Sent:* Tuesday, March 06, 2018 at 10:50 AM
*Subject:* Re: [Interest] How to render small Images decently on non
retina displays with QtQuick?
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not see
it in the email body. The file is called isotope.png)
import QtQuick 2.4
Item {
id: root
implicitWidth: 100
implicitHeight: 100
property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor
Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}
ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
<Mail Attachment.png><Mail Attachment.png>
<Mail Attachment.png>
Can you elaborate on “really bad”, and also share a screenshot?
*From:* Interest [mailto:interest-bounces+mitch
Santos
*Sent:* Tuesday, 6 March 2018 4:27 PM
*Subject:* [Interest] How to render small Images decently on non retina
displays with QtQuick?
Hi,
I have a simple question.
*How to render small Images decently on non retina displays with QtQuick?*
In my apps, I use images for icons and logos. They are all big enough to
be displayed correctly.
However, on non Retina displays they get really bad! And on retine
display they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________ Interest mailing list
ilman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Xavier
--
Xavier
Nuno Santos
2018-03-06 16:55:23 UTC
Permalink
Xavier,

SVG did the trick!!!!

I just had to add it to resources and pass it to the image element.

Looking great now!! :)

Thank you all for your help!!!!

Best,

Nuno
I think that you just have to link the svg module, if I remember correctly, then in QML just use it as source of an Image item.
The only think is that you have to fix the size of the item as the sourceSize have no sense here.
I have never used SVG in QtQuick.
What can be used to render SVG’s in QtQuick?
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG (vectoring it) or using distance field technique.
Maybe this has something to do with with mipMapping/smooth? It looks like it's not anti-aliasing?
Sent: Tuesday, March 06, 2018 at 10:50 AM
Subject: Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not see it in the email body. The file is called isotope.png)
import QtQuick 2.4
Item {
id: root
implicitWidth: 100
implicitHeight: 100
property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor
Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}
ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
<Mail Attachment.png><Mail Attachment.png>
<Mail Attachment.png>
Can you elaborate on “really bad”, and also share a screenshot?
Sent: Tuesday, 6 March 2018 4:27 PM
Subject: [Interest] How to render small Images decently on non retina displays with QtQuick?
Hi,
I have a simple question.
How to render small Images decently on non retina displays with QtQuick?
In my apps, I use images for icons and logos. They are all big enough to be displayed correctly.
However, on non Retina displays they get really bad! And on retine display they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest <http://lists.qt-project.org/mailman/listinfo/interest>
--
Xavier
--
Xavier
Nuno Santos
2018-03-06 23:16:44 UTC
Permalink
Does anyone knows which modules we need to have compiled in order to make svg support work?

I depend on a static build of Qt and while I was able to use SVG with the prebuilt Qt, I couldn’t make use of it using my static build.

I realised I was missing qtsvg module but even after including it in the build it still says "unsupported graphic format”

Any ideas?

Thx!

Regards,

Nuno
Post by Nuno Santos
Xavier,
SVG did the trick!!!!
I just had to add it to resources and pass it to the image element.
Looking great now!! :)
Thank you all for your help!!!!
Best,
Nuno
<Screen Shot 2018-03-06 at 16.54.50.png>
I think that you just have to link the svg module, if I remember correctly, then in QML just use it as source of an Image item.
The only think is that you have to fix the size of the item as the sourceSize have no sense here.
I have never used SVG in QtQuick.
What can be used to render SVG’s in QtQuick?
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG (vectoring it) or using distance field technique.
Maybe this has something to do with with mipMapping/smooth? It looks like it's not anti-aliasing?
Sent: Tuesday, March 06, 2018 at 10:50 AM
Subject: Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not see it in the email body. The file is called isotope.png)
import QtQuick 2.4
Item {
id: root
implicitWidth: 100
implicitHeight: 100
property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor
Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}
ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
<Mail Attachment.png><Mail Attachment.png>
<Mail Attachment.png>
Can you elaborate on “really bad”, and also share a screenshot?
Sent: Tuesday, 6 March 2018 4:27 PM
Subject: [Interest] How to render small Images decently on non retina displays with QtQuick?
Hi,
I have a simple question.
How to render small Images decently on non retina displays with QtQuick?
In my apps, I use images for icons and logos. They are all big enough to be displayed correctly.
However, on non Retina displays they get really bad! And on retine display they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest <http://lists.qt-project.org/mailman/listinfo/interest>
--
Xavier
--
Xavier
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Giuseppe D'Angelo
2018-03-06 23:35:53 UTC
Permalink
Post by Nuno Santos
Does anyone knows which modules we need to have compiled in order to make svg support work?
I depend on a static build of Qt and while I was able to use SVG with
the prebuilt Qt, I couldn’t make use of it using my static build.
I realised I was missing qtsvg module but even after including it in the
build it still says "unsupported graphic format”
Any ideas?
You need

QTPLUGIN += qsvg

in your .pro. See
Post by Nuno Santos
https://doc.qt.io/qt-5/plugins-howto.html#static-plugins
HTH,
--
Giuseppe D'Angelo | ***@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
Nuno Santos
2018-03-07 00:45:08 UTC
Permalink
Worked like charm!

Thanks for your prompt reply.

Best!

Nuno
Post by Giuseppe D'Angelo
Post by Nuno Santos
Does anyone knows which modules we need to have compiled in order to make svg support work?
I depend on a static build of Qt and while I was able to use SVG with the prebuilt Qt, I couldn’t make use of it using my static build.
I realised I was missing qtsvg module but even after including it in the build it still says "unsupported graphic format”
Any ideas?
You need
QTPLUGIN += qsvg
in your .pro. See
Post by Nuno Santos
https://doc.qt.io/qt-5/plugins-howto.html#static-plugins
HTH,
--
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Uwe Rathmann
2018-03-07 08:08:29 UTC
Permalink
Post by Nuno Santos
I just had to add it to resources and pass it to the image element.
Using Image works, but its implementation is far from being optimal in
combination with SVGs. For small applications with only few SVGs this
might be no problem, but when having many of them it is often a serious
performance killer for the startup time.

In short: the overall strategy of Qt/Quick is to cache as much and as
early as possible - in case of the Image/SVG too early:

it loads and renders the SVG according to its sourceSize as soon as it
sees the URL. But in case of scalable graphic formats the sourceSize
( usually the viewBox of the SVG ) does only provide the aspect ratio,
but not the size that is needed to be rendered.

This is usually solved by binding the sourceSize to the size being
calculated from the layout code, but ...

When having a layout system that relies on binding the implicit sizes the
geometry of each item changes several times until it reaches its final
size - each time re-rendering the SVG.

( In fact it gets re-rendered twice each time, because binding a size
leads to separate updates of width and height )

I remember an application, where SVGs have been re-rendered more than 10
times before they had their final size. This application had more than
1000 SVGs and - even if only few of them were visible in the beginning
the caching strategy of Qt/QQuickImage lead to more than 10000 image re-
rendering operations.

So I would recommend for every application having many SVGs: never ever
use Image and always go with QQuickPaintedItem.

Uwe
Xavier Bigand
2018-03-07 09:11:06 UTC
Permalink
This is good to know, I personally never fall in a such case, but I will
keep that in a corner of my head.

Thank you.
Post by Uwe Rathmann
Post by Nuno Santos
I just had to add it to resources and pass it to the image element.
Using Image works, but its implementation is far from being optimal in
combination with SVGs. For small applications with only few SVGs this
might be no problem, but when having many of them it is often a serious
performance killer for the startup time.
In short: the overall strategy of Qt/Quick is to cache as much and as
it loads and renders the SVG according to its sourceSize as soon as it
sees the URL. But in case of scalable graphic formats the sourceSize
( usually the viewBox of the SVG ) does only provide the aspect ratio,
but not the size that is needed to be rendered.
This is usually solved by binding the sourceSize to the size being
calculated from the layout code, but ...
When having a layout system that relies on binding the implicit sizes the
geometry of each item changes several times until it reaches its final
size - each time re-rendering the SVG.
( In fact it gets re-rendered twice each time, because binding a size
leads to separate updates of width and height )
I remember an application, where SVGs have been re-rendered more than 10
times before they had their final size. This application had more than
1000 SVGs and - even if only few of them were visible in the beginning
the caching strategy of Qt/QQuickImage lead to more than 10000 image re-
rendering operations.
So I would recommend for every application having many SVGs: never ever
use Image and always go with QQuickPaintedItem.
Uwe
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Xavier
Nuno Santos
2018-03-07 10:02:42 UTC
Permalink
Uwe,

Thanks for things insight!

Regards,

Nuno
Post by Uwe Rathmann
Post by Nuno Santos
I just had to add it to resources and pass it to the image element.
Using Image works, but its implementation is far from being optimal in
combination with SVGs. For small applications with only few SVGs this
might be no problem, but when having many of them it is often a serious
performance killer for the startup time.
In short: the overall strategy of Qt/Quick is to cache as much and as
it loads and renders the SVG according to its sourceSize as soon as it
sees the URL. But in case of scalable graphic formats the sourceSize
( usually the viewBox of the SVG ) does only provide the aspect ratio,
but not the size that is needed to be rendered.
This is usually solved by binding the sourceSize to the size being
calculated from the layout code, but ...
When having a layout system that relies on binding the implicit sizes the
geometry of each item changes several times until it reaches its final
size - each time re-rendering the SVG.
( In fact it gets re-rendered twice each time, because binding a size
leads to separate updates of width and height )
I remember an application, where SVGs have been re-rendered more than 10
times before they had their final size. This application had more than
1000 SVGs and - even if only few of them were visible in the beginning
the caching strategy of Qt/QQuickImage lead to more than 10000 image re-
rendering operations.
So I would recommend for every application having many SVGs: never ever
use Image and always go with QQuickPaintedItem.
Uwe
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Shawn Rutledge
2018-03-07 11:45:32 UTC
Permalink
Post by Uwe Rathmann
Post by Nuno Santos
I just had to add it to resources and pass it to the image element.
Using Image works, but its implementation is far from being optimal in
combination with SVGs. For small applications with only few SVGs this
might be no problem, but when having many of them it is often a serious
performance killer for the startup time.
In short: the overall strategy of Qt/Quick is to cache as much and as
it loads and renders the SVG according to its sourceSize as soon as it
sees the URL. But in case of scalable graphic formats the sourceSize
( usually the viewBox of the SVG ) does only provide the aspect ratio,
but not the size that is needed to be rendered.
This is usually solved by binding the sourceSize to the size being
calculated from the layout code, but ...
When having a layout system that relies on binding the implicit sizes the
geometry of each item changes several times until it reaches its final
size - each time re-rendering the SVG.
( In fact it gets re-rendered twice each time, because binding a size
leads to separate updates of width and height )
I remember an application, where SVGs have been re-rendered more than 10
times before they had their final size. This application had more than
1000 SVGs and - even if only few of them were visible in the beginning
the caching strategy of Qt/QQuickImage lead to more than 10000 image re-
rendering operations.
So I would recommend for every application having many SVGs: never ever
use Image and always go with QQuickPaintedItem.
It should also be considered a bug IMO. Do you know of any reported bugs about this?
Uwe Rathmann
2018-03-07 13:10:25 UTC
Permalink
Hi Shawn,
Post by Shawn Rutledge
It should also be considered a bug IMO.
The only obvious part of the whole disaster that IMO qualifies as a "bug"
is the fact, that binding a size ends up in 2 calls - but AFAIK this is
not specific to QQuickImage.

Maybe one could say, that QQuickImage shouldn't do any updates before
updatePolish, but this would be the opposite of the overall "as soon as
much as possible" caching strategy implemented in Qt/Quick.

I once derived a small class from QQuickImage ( https://github.com/uwerat/
qskinny/blob/master/playground/images/Image.h ), to avoid some of these
issues, but I never used it as we later decided to go with writing our
own code for displaying images.

This code uses a class that is called QskGraphic, what in the end is a
record/replay paint device - similar to QPicture, but tailored for
scalable vector graphics.

This way we can precompile our SVGs at build time into QPainter commands
and store them into as something we call a qvg file. As we have small
iconic graphics only we can load those files from disk in updatePolish
and replay the commands in updatePaintNode without needing any cache at
all.

( If you are interested: the qvgviewer example in qskinny uses it. )

Maybe a side node: IIRC creating a QImage and translating it into a FBO
seems to be faster - when having simple icons - than creating the FBO
directly. Looks like the tesselation done inside the OpenGL paint engine
is as expensive as what the raster paint engine has to do for pixeling
down the RGB values.

( But this is something I noticed 2 year ago and might have changed in
the meantime ? )

Uwe
Jason H
2018-03-07 19:55:03 UTC
Permalink
Sent: Wednesday, March 07, 2018 at 8:10 AM
Subject: Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
Hi Shawn,
...
I once derived a small class from QQuickImage ( https://github.com/uwerat/
qskinny/blob/master/playground/images/Image.h ), to avoid some of these
issues, but I never used it as we later decided to go with writing our
own code for displaying images.
This code uses a class that is called QskGraphic, what in the end is a
record/replay paint device - similar to QPicture, but tailored for
scalable vector graphics.
How is QPicture not appropriate for SVG?
Uwe Rathmann
2018-03-08 06:18:05 UTC
Permalink
Post by Jason H
How is QPicture not appropriate for SVG?
At the time, when Qt changed its APIs from integers to doubles ( Qt 4 )
QPicture::boundingRect() was forgotten, what makes layouting of scaled
pictures too inaccurate.

Another important detail are non cosmetic pens. You need to know about
them as they might grow outside the bounding rectangle.

Beyond that QPicture stores painter commands in a platform-independent
format, what makes it less performant and the file sizes are larger.

In the end ( not yet implemented ) I want to mmap my precompiled SVGs
into memory. Then, copying all precompiled SVGs at boot time into a RAM
drive and you have almost zero overhead for IO.

Uwe
Shawn Rutledge
2018-03-15 14:17:00 UTC
Permalink
Post by Uwe Rathmann
Post by Jason H
How is QPicture not appropriate for SVG?
At the time, when Qt changed its APIs from integers to doubles ( Qt 4 )
QPicture::boundingRect() was forgotten, what makes layouting of scaled
pictures too inaccurate.
Another important detail are non cosmetic pens. You need to know about
them as they might grow outside the bounding rectangle.
Beyond that QPicture stores painter commands in a platform-independent
format, what makes it less performant and the file sizes are larger.
In the end ( not yet implemented ) I want to mmap my precompiled SVGs
into memory. Then, copying all precompiled SVGs at boot time into a RAM
drive and you have almost zero overhead for IO.
That sounds interesting. What format do you want to precompile them to?
Uwe Rathmann
2018-03-15 19:05:29 UTC
Permalink
Post by Shawn Rutledge
That sounds interesting. What format do you want to precompile them to?
Well, as all we need is to restore the members of a class exactly, like
they have been in memory, before we wrote them to disk, there should be a
way to do this without having to write a parser.

But this is all I have to offer so far. The idea of using mmap exists
since the very beginning of our project, but as we already have no
performance issues with how we load the images today it has a low
priority.

The format we are using today can be found here: https://github.com/
uwerat/qskinny/blob/master/src/graphic/QskGraphicIO.cpp.

To be complete I also implemented embedded QImage/QPixmap, but in reality
we only have QPainterPath vector data and state change informations -
both stored stored in a QVector. Beside that there is some Meta Data
( supporting proper layouting of scaled vector graphics ) - so all in all
it should be doable.

--

Unfortunately Qt development never really saw much potential in using
vector graphic formats for writing user interfaces. It was never a first
class citizen for widgets, but with Qt/Quick the idea totally got lost,
as the one-window-always-in-fullscreen use case has become dominant.

I remember, that there once was a page ( maybe it is still there, but I
can't find it ) in the Qt documentation, that explicitly mentioned the
combination of Layouts and SVG as solution for writing scalable user
interfaces.

But IIRC SVGs do not even exist in the complete Qt/Quick API and the thin
layer ( a.k.a Qt/Quick Layouts ) on top of QGridLayoutEngine does not
even forward the available features ( f.e dynamic constraints ) of this
powerful class to the user.

If you like you can compare it with the layout system I have implemented
on top of the same engine: https://github.com/uwerat/qskinny/tree/master/
src/layouts. It is more or less the same, what the widget layouts offer +
a couple of extras I always missed in the past when using them.

ciao,
Uwe

Shantanu Tushar
2018-03-15 13:20:51 UTC
Permalink
Post by Xavier Bigand
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG
(vectoring it) or using distance field technique.
I had this question for a while now - if we can use SVGs for showing
application icons (which will then look good with any dimensions / DPI),
why is it common to use images instead? There's obviously some benefit to
images as people take pains to bundle multiple versions for different DPIs,
I wanted to know what they are. Most of the stuff I can find online is
always talking about websites and "web apps" which might not all apply to
desktop applications.

I see that Uwe has pointed out a performance issue which can happen because
of multiple renderings due to size changes. Is that it? Or are there other
reasons behind preferring PNG icons over SVG?
Post by Xavier Bigand
Maybe this has something to do with with mipMapping/smooth? It looks like
it's not anti-aliasing?
*Sent:* Tuesday, March 06, 2018 at 10:50 AM
*Subject:* Re: [Interest] How to render small Images decently on non
retina displays with QtQuick?
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not see
it in the email body. The file is called isotope.png)
import QtQuick 2.4
Item {
id: root
implicitWidth: 100
implicitHeight: 100
property real padding: 0
property alias imageSource: icon.source
property color imageColor: controller.settings.foregroundColor
Image {
id: icon
anchors.fill: parent
anchors.margins: root.padding
fillMode: Image.PreserveAspectFit
}
ColorOverlay {
id: overlay
source: icon
anchors.fill: icon
color: root.imageColor
}
}
Can you elaborate on “really bad”, and also share a screenshot?
*From:* Interest [mailto:interest-bounces+mitch
Santos
*Sent:* Tuesday, 6 March 2018 4:27 PM
*Subject:* [Interest] How to render small Images decently on non retina
displays with QtQuick?
Hi,
I have a simple question.
*How to render small Images decently on non retina displays with QtQuick?*
In my apps, I use images for icons and logos. They are all big enough to
be displayed correctly.
However, on non Retina displays they get really bad! And on retine
display they appear perfectly.
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________ Interest mailing list
ilman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Xavier
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Shantanu Tushar (UTC +0530)
shantanu.io
Shawn Rutledge
2018-03-15 14:26:41 UTC
Permalink
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG (vectoring it) or using distance field technique.
I had this question for a while now - if we can use SVGs for showing application icons (which will then look good with any dimensions / DPI), why is it common to use images instead? There's obviously some benefit to images as people take pains to bundle multiple versions for different DPIs, I wanted to know what they are. Most of the stuff I can find online is always talking about websites and "web apps" which might not all apply to desktop applications.
I see that Uwe has pointed out a performance issue which can happen because of multiple renderings due to size changes. Is that it? Or are there other reasons behind preferring PNG icons over SVG?
I think it’s mainly that SVG rendering is slow because it’s done in software, and also that qtsvg only supports SVG Tiny, so it can’t render everything that you can design in Inkscape, for example. You have keep the SVGs simple and avoid features that we don’t support (blurs, gradients, line endings/arrowheads and lots more). If you want full SVG support you can use webkit/webengine, but that’s overkill in many applications.

Speaking of distance field: If your icons are monochrome, you might consider making a custom icon font for your application. You can start with something like Font Awesome, edit it to include only the icons you need, and add more custom-designed icons as necessary. Then you can render an icon with a Text element. But finding a suitable icon editing program is up to you in that case. I did it with FontForge once a couple of years ago.

In the future I think it will make sense to use PDF for vector icons too (in color, even). (Some frameworks already can do this.) Then instead of an icon font, you could have one PDF file with all the icons for your app, one icon per “page”. I hope to eventually support using a PDF file with an ordinary Image in QML, but we have to add API for selecting the page, and there are other issues with caching and so on. I had patches to get it mostly working a couple of years ago, it just wasn’t 100% ready for integration.
Nikolai Tasev
2018-03-15 14:58:52 UTC
Permalink
Post by Shawn Rutledge
In the future I think it will make sense to use PDF for vector icons
too (in color, even). (Some frameworks already can do this.) Then
instead of an icon font, you could have one PDF file with all the
icons for your app, one icon per “page”. I hope to eventually support
using a PDF file with an ordinary Image in QML, but we have to add API
for selecting the page, and there are other issues with caching and so
on. I had patches to get it mostly working a couple of years ago, it
just wasn’t 100% ready for integration.
The PDF format specification is even more complex than the SVG one аs it
is used also to control printing output. The good PDF RIPs are all
proprietary. I had quite a lot difficulties using Ghostscript and
Poppler until I switched to  a library with a paid license. So it will
be again limited to a subset of the specification and maybe slow.
Shawn Rutledge
2018-03-15 15:14:14 UTC
Permalink
In the future I think it will make sense to use PDF for vector icons too (in color, even). (Some frameworks already can do this.) Then instead of an icon font, you could have one PDF file with all the icons for your app, one icon per “page”. I hope to eventually support using a PDF file with an ordinary Image in QML, but we have to add API for selecting the page, and there are other issues with caching and so on. I had patches to get it mostly working a couple of years ago, it just wasn’t 100% ready for integration.
The PDF format specification is even more complex than the SVG one аs it is used also to control printing output. The good PDF RIPs are all proprietary. I had quite a lot difficulties using Ghostscript and Poppler until I switched to a library with a paid license. So it will be again limited to a subset of the specification and maybe slow.
QtPDF is using pdfium. http://code.qt.io/cgit/qt-labs/qtpdf.git It is complex third-party code (but open source), and the rendering is again done in software, but it seems fast enough. I haven’t tried to compare rendering times: the same drawing in SVG vs. PDF.
Mitch Curtis
2018-03-15 16:14:45 UTC
Permalink
-----Original Message-----
On Behalf Of Shawn Rutledge
Sent: Thursday, 15 March 2018 3:27 PM
Subject: Re: [Interest] How to render small Images decently on non retina
displays with QtQuick?
Post by Xavier Bigand
Hi,
If your sample picture is relevant I can suggest you to convert it as SVG
(vectoring it) or using distance field technique.
Post by Xavier Bigand
I had this question for a while now - if we can use SVGs for showing
application icons (which will then look good with any dimensions / DPI), why
is it common to use images instead? There's obviously some benefit to
images as people take pains to bundle multiple versions for different DPIs, I
wanted to know what they are. Most of the stuff I can find online is always
talking about websites and "web apps" which might not all apply to desktop
applications.
Post by Xavier Bigand
I see that Uwe has pointed out a performance issue which can happen
because of multiple renderings due to size changes. Is that it? Or are there
other reasons behind preferring PNG icons over SVG?
I think it’s mainly that SVG rendering is slow because it’s done in software,
and also that qtsvg only supports SVG Tiny, so it can’t render everything that
you can design in Inkscape, for example. You have keep the SVGs simple and
avoid features that we don’t support (blurs, gradients, line
endings/arrowheads and lots more). If you want full SVG support you can
use webkit/webengine, but that’s overkill in many applications.
Speaking of distance field: If your icons are monochrome, you might consider
making a custom icon font for your application. You can start with something
like Font Awesome, edit it to include only the icons you need, and add more
custom-designed icons as necessary. Then you can render an icon with a
Text element. But finding a suitable icon editing program is up to you in that
case. I did it with FontForge once a couple of years ago.
Or just use Fontello:

http://fontello.com/
In the future I think it will make sense to use PDF for vector icons too (in
color, even). (Some frameworks already can do this.) Then instead of an
icon font, you could have one PDF file with all the icons for your app, one icon
per “page”. I hope to eventually support using a PDF file with an ordinary
Image in QML, but we have to add API for selecting the page, and there are
other issues with caching and so on. I had patches to get it mostly working a
couple of years ago, it just wasn’t 100% ready for integration.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Uwe Rathmann
2018-03-15 17:26:12 UTC
Permalink
Post by Shawn Rutledge
Post by Shantanu Tushar
I see that Uwe has pointed out a performance issue which can happen
because of multiple renderings due to size changes. Is that it? Or are
there other reasons behind preferring PNG icons over SVG?
I think it’s mainly that SVG rendering is slow because it’s done in
software, ...
In our use case we have more of 1000 different SVGs - all of them small
and simple - the type of icons you usually have on buttons.
For those I can't confirm, having any performance problems with rendering
them.

The problems we noticed are related to the classes in Qt/Quick core:

a) QQuickImage

The caching strategy of QQuickImage, does not take into count, that
scalable graphic formats do not offer a reasonable source size and that
it doesn't make sense to render anything before the layout system has
calculated the final size for the image.

But this one is not a serious problem as long as you are aware that
QQuickImage is for raster data formats and for all sort of vector base
images better use QQuickPaintedItem.

b) QQuickItem

QQuickItem and friends are not careful about avoiding geometryChanged
notifications. Binding sizes results in setting width/height in 2
separate call resulting in 2 geometryChange events.

Even worse: QQuickItem does not even have a public API where you can set
its geometry in one call. Without using the private APIs you have to set
size and position in 2 calls - always resulting in 2 geometryChanged
notifications.

And here we are talking of a public C++ API - the one for the base class
of all Qt/Quick Items !

c) Layouting

With QWidgets layout update requests are indicated by an event
( LayoutRequest ) to the parent and usually processed asynchronously.
This way several layout requests can be collected and lead to one
calculation only.

When binding implicitSize properties this is not the case and leads to
several updates - often irrelevant as only the last one is important.

In QSkinny I implemented a layout system, that is similar to what QWidgets
does. Layout Requests are not processed before updatePolish.

Something I have not yet fixed in our environment is, that layouting
always has to be done in top/down order. That requires sorting the items
in the to-be-polished list. I would expect to see some nice improvements
in our ( already almost non existing ) startup time.

d) Once more QQuickImage

From what I written above my conclusion is, that no class should do any
expensive operation in geometryChanged.

--

Finally an unrelated comment on QQuickItem::geometryChanged,
QQuickItem::itemChange and QQuickItemChangeListener:

why do those APIs exist at all ?

Sending events is a well established mechanism that exists since ever and
event filtering is public, available and more powerful ( swallow events )
than those listeners.

ciao,
Uwe
Allan Sandfeld Jensen
2018-03-06 16:44:19 UTC
Permalink
Post by Nuno Santos
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards…
Original image attached (it is white over transparent so you will not see it
in the email body. The file is called isotope.png)
Looks like you dont have antialiasing enabled. It is a good idea in general.
Just add the line "antialiasing : false" to the rendered item.

'Allan
Allan Sandfeld Jensen
2018-03-06 16:47:10 UTC
Permalink
Post by Allan Sandfeld Jensen
Post by Nuno Santos
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards…
Original image attached (it is white over transparent so you will not see
it in the email body. The file is called isotope.png)
Looks like you dont have antialiasing enabled. It is a good idea in general.
Just add the line "antialiasing : false" to the rendered item.
I meant 'antialiasing: true' of course. Looks like it is indeed off by
default http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html#antialiasing and that will result in terrible scaled images.

'Allan
Nuno Santos
2018-03-06 16:49:48 UTC
Permalink
Allan,

I have tried to enable antialiasing to true but it didn’t made any difference

:(
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
Post by Nuno Santos
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards…
Original image attached (it is white over transparent so you will not see
it in the email body. The file is called isotope.png)
Looks like you dont have antialiasing enabled. It is a good idea in general.
Just add the line "antialiasing : false" to the rendered item.
I meant 'antialiasing: true' of course. Looks like it is indeed off by
default http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html#antialiasing and that will result in terrible scaled images.
'Allan
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Xavier Bigand
2018-03-06 16:51:13 UTC
Permalink
The anti-aliasing only works on edges except for the Super Sampling AA.
Post by Nuno Santos
Allan,
I have tried to enable antialiasing to true but it didn’t made any
difference
:(
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
Post by Nuno Santos
Mitch,
Thanks for your reply.
You are right. I’m not playing all the cards

Original image attached (it is white over transparent so you will not
see
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
Post by Nuno Santos
it in the email body. The file is called isotope.png)
Looks like you dont have antialiasing enabled. It is a good idea in
general.
Post by Allan Sandfeld Jensen
Post by Allan Sandfeld Jensen
Just add the line "antialiasing : false" to the rendered item.
I meant 'antialiasing: true' of course. Looks like it is indeed off by
default http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-
renderer.html#antialiasing and that will result in terrible scaled images.
Post by Allan Sandfeld Jensen
'Allan
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Xavier
ekke
2018-03-06 15:48:52 UTC
Permalink
I'm using QtQuickControls2 and Qt::AA_EnableHighDpiScaling
and so all my images are deployed with my app in different solutions

per ex a 24x24px Icon
test.png (24x24) -- for 160 dpi --
***@2x.png (48x48)
***@3x.png (72x72)
***@4x.png (96x96)

and so for all devices with all kind of dpi by magic the Icons and
Images are looking same

if you don't use the HighDpiScaling you can try to check the density and
then scale your Image or deploy your Images/Icons similar to @2x, ...
and select the right one for dpi of actual device running on

ekke
Hi,
I have a simple question. 
*How to render small Images decently on non retina displays with QtQuick?*
*
*
In my apps, I use images for icons and logos. They are all big enough
to be displayed correctly. 
However, on non Retina displays they get really bad! And on retine
display they appear perfectly. 
What is the rule of thumb to use QtQuick Image element on on retina displays?
Thx!
Regards,
Nuno
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Loading...