Minutes Monday Plasma hangout

[David Edmundson]

On Wed, Feb 19, 2014 at 8:10 PM, Mark Gaiser <markg85 at gmail.com> wrote:
> On Wed, Feb 19, 2014 at 6:47 PM, Martin Graesslin <mgraesslin at kde.org> wrote:
>>
>> On Wednesday 19 February 2014 18:11:12 David Edmundson wrote:
>> > On Mon, Feb 17, 2014 at 1:26 PM, Sebastian Kügler <sebas at kde.org> wrote:
>> > > Plasma Meeting February, 17th, 2014
>> > >
>> > > Present: Alex Fiestas, David Edmundson, Giorgos Tsiapaliokas, Marco
>> > > Martin,
>> > > Martin Grässlin, Martin Klapetek, Jens Reuterberg, Antonis Tsiapaliokas,
>> > > Sebastian Kügler, Vishesh Handa,
>> > >
>> > >
>> > > Alex:
>> > > - finished wallet work (it's secure now!)
>> > > - works on kdeinit now (benchmarking and profiling to make it lighter)
>> > > - researches overlap with systemd, where can we use systemd?
>> > >
>> > > David:
>> > > - started notes plasmoid (davidedmundson/notes)
>> > > - debugging proxymodel, fixed problem
>> > > - fixed toolbox problems
>> > > - various improvements in tooltip
>> > > - other bugfixes
>> > > - profiling: looking at memory consumption of Plasma
>> >
>> > I had a look at the code for QSGTexture, it does indeed store a cache
>> > of the texture as a QImage. .
>> >
>> > Right now we do two paints SVG->QPixmap (the cache) and
>> > QPixmap->QImage (via QQuickPaintedItem).
>> >
>> > This second paint is very problematic for 3 reasons:
>> > 1) it's another paint!
>> > 2) we store the image twice
>> > 3) we are no longer implicitly sharing the same image when we do a
>> > paint across images as opposed to copying a QImage.
>> >
>> > I have just managed to make Plasma::SvgItem provide QSGNodes rather
>> > than inheriting from QQuickPaintedItem.
>> >
>> > This is half way there, the next step is to port most of
>> > Plasma::Theme/Plasma::SVG to use QImage instead of QPixmap throughout
>> > (including the cache) so that we can avoid the deep copies and the
>> > secondary QPainting. This will mean breaking the public API(!), but it
>> > will be totally worth it.
>>
>> Full support for breaking the API in that aspect. Will break KWin, but I like
>> it (we have the same problem: getting the pixmap and converting it to qimage).
>>
>> Cheers
>> Martin
>>
> Huh, i'm trying to understand the change since it seems counter
> intuitive if i read the Qt docs.
>
> The Qt documentation says: "QPixmap is designed and optimized for
> showing images on screen" and "Typically, the QImage class is used to
> load an image file, optionally manipulating the image data, before the
> QImage object is converted into a QPixmap to be shown on screen.
> Alternatively, if no manipulation is desired, the image file can be
> loaded directly into a QPixmap."
>

Yes, it is counter-intuitive and it's a good question.

Basically it comes down to those docs being outdated.

QPixmap is (was) fast for on screen things because each QPixmap was an
X texture underneath.
For Qt5, that's no longer true and more importantly we're not
rendering through X, we're painting into openGL.

> Both quotes lead me to think that QPixmap is the one to use, not QImage.
>
> Yes, i'm confused :)
> If someone would be so kind to explain the technical details why a
> QImage makes more sense rather then a QPixmap?
>
> As a related question, would it make sense to skip QImage entirely and
> store it as "QOpenGLFramebufferObject" or "QSGTexture" objects?
>
That's almost what we're doing :)

We still need a wait to render from SVG into something we can use;
which means going via QPixmap or QImage. As you noted earlier QImage
is faster for manipulation.

The docs for creating QSGTexture say you should normally create it via QWindow::
createTextureFromImage(QImage), and QSGTexture uses a QImage internally.


David

> Cheers,
> Mark
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel