[Webkit-unassigned] [Bug 28862] [Qt][API] Add a new QGraphicsWidget based version of the "QWebView"

[bugzilla-daemon at webkit.org]

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





--- Comment #28 from Simon Hausmann <hausmann at webkit.org>  2009-09-08 07:55:06 PDT ---
(In reply to comment #22)
> > +void QWebGraphicsItemPrivate::_q_doScroll(int dx, int dy, const QRect& rectToScroll)
> > +{
> > +    q->scroll(qreal(dx), qreal(dy), QRectF(rectToScroll));
> > +}
> 
> I found out that this does not really work if I subclass QWebGraphicsItem.
> An example: I have my customized QWebGraphicsItem that clips the painting so
> that the corners are rounded. When this function is invoked, say scrolling
> vertically, the whole painted item is scrolled, meaning the bottom rounded
> corners are also scrolled. The correct thing of course that the _contents_ of
> the web page is scrolled, not merely the item.
> The real fix would be to call update, instead of scroll. I understand that this
> is optimization issue, but I'd rather have a correctly painted item than a fast
> but garbage one.

Hehe, well, being able to _scroll_ the webpage instead of repainting it
entirely is one of the primary purposes of QWebGraphicsItem. With a QWebView
embedded using a QGraphicsProxyWidget we get exactly that repaint-on-scroll
behaviour that makes it so slow to use.

I agree with Kenneth that this is either a QGraphicsView bug or we lack a
mechanism to determine if it is safe to scroll or not. In the worst case we
make it a property of QWebGraphicsItem (scrollMode?), in the best case we can
detect this situation automatically, similar to QGraphicsItem::scroll()'s
implementation.

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