On Wed, Feb 19, 2014 at 9:03 PM, David Edmundson <da...@davidedmundson.co.uk> wrote: > On Wed, Feb 19, 2014 at 8:10 PM, Mark Gaiser <mark...@gmail.com> wrote: >> On Wed, Feb 19, 2014 at 6:47 PM, Martin Graesslin <mgraess...@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 <se...@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, Martin: thank you both very much for the clear explanation. I was using QPixmap where i needed an image, but it looks like QImage would be the choice from now on. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
