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 > Cheers, > Mark > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
