[Webkit-unassigned] [Bug 41682] Certain page elements cause XGetImage and software fallback rendering

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41682


Nikolas Zimmermann <zimmermann at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[Qt] Certain page elements  |Certain page elements cause
                   |cause XGetImage and         |XGetImage and software
                   |software fallback rendering |fallback rendering
           Keywords|Qt                          |
                 CC|                            |zimmermann at kde.org




--- Comment #4 from Nikolas Zimmermann <zimmermann at kde.org>  2010-07-14 06:54:09 PST ---
Interessting trace diagram.
The diagram shows that Image::drawTiled() (called from RenderBoxModelObject::paintFillLayerExtended) calls Image::drawPattern(). When debugging on Safari/Mac, that code path is never taken.

Snippet from WebCore/platform/graphics/Image.cpp:

void Image::drawTiled(GraphicsContext* ctxt, const FloatRect& destRect, const FloatPoint& srcPoint, const FloatSize& scaledTileSize, ColorSpace styleColorSpace, CompositeOperator op)
{
...

    // Check and see if a single draw of the image can cover the entire area we are supposed to tile.    
    if (oneTileRect.contains(destRect)) { // <- LINE 130
....
        draw(ctxt, destRect, visibleSrcRect, styleColorSpace, op);
        return;
    }
...
    drawPattern(ctxt, tileRect, patternTransform, oneTileRect.location(), styleColorSpace, op, destRect);
..
}

On Mac, it always returns true in the check on line 130, and never calls drawPattern.
I suspect it may be a problem with ImageQt, you might want to set a breakpoint there, and verify whether it returns false in the oneTileRect.contains(destRect) check.

When following the trace diagram it's obvious that you end up creating a QBrush with a QPixmap, through the drawPattern() code path. That's a QBrush, with QStyle::TexturePattern - which can be verified, as QTexturedBrushData is present at the bottom of the diagram. Later on QSpanData::setup():

void QSpanData::setup(const QBrush &brush, int alpha, QPainter::CompositionMode compositionMode)
{
...
    case Qt::TexturePattern:
        type = Texture;
        if (!tempImage)
            tempImage = new QImage();

        if (qHasPixmapTexture(brush) && brush.texture().isQBitmap())
            *tempImage = rasterBuffer->colorizeBitmap(brush.textureImage(), brush.color());
        else
            *tempImage = brush.textureImage();
        initTexture(tempImage, alpha, QTextureData::Tiled, tempImage->rect());
...

convertes the brush pixmap to an image, see:

QImage QBrush::textureImage() const
{
    return d->style == Qt::TexturePattern
                     ? (static_cast<QTexturedBrushData *>(d.data()))->image()
                     : QImage();
}

struct QTexturedBrushData : public QBrushData
{
..
    QImage &image() {
        if (m_image.isNull() && m_pixmap)
            m_image = m_pixmap->toImage();
        return m_image;
    }
}

This is the reason you're seeing the XGetImage calls, see qt-source/gui/image/qpixmap_x11.cpp:
QImage QX11PixmapData::toImage() const
{
..

    XImage *xi = XGetImage(X11->display, hd, 0, 0, w, h, AllPlanes,
                           (d == 1) ? XYPixmap : ZPixmap);
...
}

Just wanted to share the trace, as I looked at it for fun :-)
(Snippets from Qt 4.6.3 btw)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.