On Tuesday 22 April 2008 15:34:23 Beto Boullosa wrote:
> Why does the output image render the whole page, except the qt-plugins? Is
> that the same problem as in printing? Could we have a fix for the QT 4.4
> final version?
Same problem as printing just with a different color. With WebKit we have
something called RenderTree. When doing any kind of painting (printing,
drawing to image, drawing to screen) we go to the root to the RenderTree and
start to paint. The issue is we do not draw Widgets when we are asked to draw
them (WebCore::Widget::paint has no implementation). The QWidget is drawn
from a different paintEvent.
This has at least the following implications:
- Drawing only works for on-screen stuff
- The z-order is wrong
- alpha, transformation (CSS3 for future Qt releases) is not applied.
When we all know this, why don't we just fix it?
- Plugins and the ugly way they are implemented (XEmbed and similar
technologies for the other windowing systems)
What could be done:
- Treat widgets with a native window and window-less widgets differently
- For the window less ones (alien) we can use QWidget::render and
things
would just work (like widgets on the graphicsview)
- Looking at the QGraphicsProxyWidget you could change WebCore::Widget
to do
the right thing and have printing/rendering to an image working for you.
We will probably look into this for Qt 4.4.x, it is definately on our (Qt
webkit developers) mind.
z.
PS: We could refuse to ever implement the NPAPI (Netscape plugins) and use
Phonon for video, Gnash/SWFDec for flash, moonlight for silverlight, so
basicly only components with source available to make them proper QWidgets.
This idea is rather unrealistic.
To unsubscribe - send "unsubscribe" in the subject to [EMAIL PROTECTED]
