On Monday 10 March 2014 14:43:42 Agocs Laszlo wrote:
> 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?

yes, I was trying to keep the explanation simple.
In fact what I do is to remote the painting commands to a HTML5 canvas, but as 
some objects shall do blinking,
which I do not want to be done via a lot of redraws, I instead create SVG 
objects which shall be intermixed displayed
with what the canvas shows (that is: primitve objects like lines, circles are 
SVG, widgets are drawn
as usual). But to have a chance that the stacking order of the SVG objects and 
the widgets is still
correct, I wanted to create the native widgets as separate canvas objects so 
that they do stack with the SVG objects.

What I think I can do to solve it is to use a global event filter, catch the 
paint events of the widgets I want to
stack correctly and redirect QWidget::render() to a paint device which knows 
the window id ... or something like that.

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

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

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

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to