[Development] QPA / QWindow / QPainter

Martin Koller kollix at aon.at
Mon Mar 10 13:14:56 CET 2014


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





More information about the Development mailing list