[Development] QPA / QWindow / QPainter

[Agocs Laszlo]

Yes, one platform window for each native widget and one backingstore per top level window. (where the toplevel's backingstore is the common backingstore for all of its child widgets)

QPA (QPlatformBackingStore) does not know anything about paint devices, paint engines and such. It allows you to provide a paint device to the widget stack or whoever performs the painting, that's all. The returned paint device could be a QImage, an OpenGL framebuffer object, a custom device with a custom paint engine doing stuff that has nothing to do with painting, etc. It does not have to be something that holds the actual pixels. The platform plugin must provide a backing store implementation however. (unless it does not care about widgets)

To implement your remoting use case, there is most likely no need to complicate things with native widgets. It is exactly the same concept as generating HTML5 canvas code or PDFs or anything else:

- Have a custom paint device that provides a custom paint engine which buffers the painting commands. Such a buffer will contain the drawing commands for all the children of a given toplevel.

- In the platform backingstore's flush send the commands over the network

Or is something, that would mandate the usage of native child widgets, missing from the picture here?

Best regards,
Laszlo

________________________________________
From: Martin Koller [kollix at aon.at]
Sent: Monday, March 10, 2014 1:14 PM
To: development at qt-project.org
Cc: Agocs Laszlo
Subject: Re: [Development] QPA / QWindow / QPainter

On Monday 10 March 2014 09:20:14 Agocs Laszlo wrote:
> > > I'm implementing a QPA plugin (now with 5.3 snapshot) and there's something
> > > I do not understand: When I use native widgets, every widget creates a
> > > QPlatformWindow, but only a toplevel window creates a
> > > QPlatformBackingStore, which is the class which delivers the paintDevice
> > > implementation.
> > >
> > > Question: when a QWidget now creates a QPainter on it, how does my QPA
> > > plugin know onto which QWindow it is currently acting, when there's only
> > > one paintDevice/one backing store ?
>
> Native child windows will work, yes. There is no difference from the backingstore's point of view. There is one backingstore (and so one instance of your QPlatformBackingStore implementation) per top-level and for each child window, native or non-native, painting happens in the same manner.

This is not clear. AFAIK there is only ONE QPlatformBackingStore per top level window but there is none for every native child widget - although Qt calls QPlatformIntegration::createPlatformWindow() for each native widget!
So I end up with the possibility to have one QPlatformWindow per widget but without a separate QPlatformBackingStore
(which I understand when you want to "blend" the alpha channels of widgets above each other)
but I still do have the problem that my QPaintEngine is called from different widgets but I can not differentiate them.

What I implement is kind of what was originally done on X11 - having ONLY the native widgets.
Something what Qt4 could do with -graphicssystem native (sending the separate paint operations over the network).
Is this simply no longer possible or what am I missing ?

> As for the painting step, QPA has almost nothing to do with it: you merely provide a QPaintDevice, the rest is up to the widgets.

I provide the paint engine, so my QPA HAS something to do with the painting. What do I misunderstand here ?

> The QPA plugin has no knowledge or interest in what's happening in there. The interesting part is the flush that happens afterwards, and in flush() you will of course know which QWindow is being flushed.

I assume this only works when I want to transport pixmaps (already composed pixel areas), but what I want
to achieve is to send the single painting commands for the different widgets over the network which have
an equivalent on the client receiving the commands.
So in fact I do not need a backing store.
Is that still possible somehow ?

--
Best regards/Schöne Grüße

Martin

()  ascii ribbon campaign - against html e-mail
/\                        - against proprietary attachments