Minutes Monday Plasma hangout

[Martin Graesslin]

On Wednesday 19 February 2014 20:10:45 Mark Gaiser 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."
> 
> Both quotes lead me to think that QPixmap is the one to use, not QImage.

The documentation is most likely not up to date or was not adjusted to the new 
world. In the good old days QPixmap referenced an XPixmap on X11. Thus it was 
designed and optimized for showing images on the screen, especially if you 
were in a load once, draw many, change never situation.

Nowadays QPixmap is just wrapping a QImage if one wants to say so.

> 
> 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?

no, one needs the QImage to load the data into the QSGTexture (you don't want 
to use the FBO for that). Of course it should be fine to create the QImage on 
the stack and discard it once it's loaded into the QSGTexture and I assume 
David is doing exactly that.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140219/73ef96d3/attachment-0001.sig>