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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
