Minutes Monday Plasma hangout
Mark Gaiser
markg85 at gmail.com
Fri Feb 21 19:02:47 UTC 2014
On Wed, Feb 19, 2014 at 9:03 PM, David Edmundson
<david at davidedmundson.co.uk> wrote:
> 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, 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.
More information about the Plasma-devel
mailing list