| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that we used QRect::isEmpty() on the item's bounding
rect intersected with the exposed region's bounding rect as a criteria
for whether the item should be drawn or not. This does not work as
expected with partial updates, where the boundingRect() of the exposed
region easily can cover the entire viewport area.
The item should *only* be drawn if its bounding rect intersects with
the exposed region (and not the exposed region's bounding rect).
Auto-test included.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem appears in the chip demo when clicking an item while scrolling the
view using the mouse wheel. The problem was that we didn't translate the
the item's old painted view rect.
There was also a problem when enabling the DontAdjustForAntialiasing flag,
causing an item to not redraw its edges. We have to adjust the rectangle
by (-1, -1, 1, 1) since QRect() and QRectF() behaves differently.
Auto-test (made by Andreas) included.
Reviewed-by: Andreas
|
| |
|
|
|
|
|
|
| |
If we pass the viewport widget as the widget pointer when rendering to
an arbitrary painter (e.g., onto a pixmap), we confuse the rendering
functions to thinking that it's the viewport's region we should render
into. So instead, when drawItems() is passed a painter that's different
from the view, we pass 0 for the widget.
|
| |
|
|
|
| |
This is necessary after we made the sceneRect grow lazily when it's not
assigned.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QStyleOptionGraphicsItem extends QStyleOption with three values:
1) matrix, 2) levelOfDetail, 3) exposedRect, and they all
involve expensive QTranform operations when calculated. We
pass style option(s) to drawItems() and paint(), but the
extended values are usually not in use. We can therefore gain
quite some nice speedup by making them opt-in with the
QGraphicsItem::ItemUsesExtendedStyleOption flag.
Additionally, QStyleOptionGraphicsItem::levelOfDetail has been
obsoleted, and a new function QStyleOptionGraphicsItem::
levelOfDetailFromTransform(const QTransform &) has been added.
Me and Andreas don't consider this change to be too controversial
even though it changes the behavior.
Auto tests still pass.
Reviewed-by: Andreas
|
| |\
| |
| |
| |
| | |
Conflicts:
tests/auto/qgraphicsview/tst_qgraphicsview.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In QGraphicsScene::_q_emitUpdated() the slot
QGrpahicsView::updateScene(QList<QRectF>) gets connected and a boolean
(connectedToScene) is set to prevent double connections. The problem is
that this boolean was not reset when the view gets a new scene.
Task-number: 253415
Reviewed-by: andreas
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that mouse move events were not forwarded to the scene
when mouse tracking was explicitly enabled on the view.
Mouse tracking is disabled by default unless the scene contains
an item that accepts hover events or has a cursor set.
A mouse move event can only occur if:
1) a mouse button is pressed while moving the mouse
2) mouse tracking is enabled
That means the part I've reverted was only hitting when
mouse tracking was explicitly enabled, which is wrong.
We always have to forward mouse move events to the scene if
the view is getting them in the first place.
Auto test included.
Reviewed-by: Andreas
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QGraphicsView::mapToScene(QRect) function assumes that QRect and
QRectF share semantics for ::bottomRight(). However, since QRect follows
Qt 3 semantics (the rect is based on viewport pixels and (0,0,1,1) is
equivalent to one pixel, topleft = bottomright), this function gives
unexpected behavior: map(0,0,1,1) gives you an empty polygon! To work
around this, users of the function need to adjust their rectangles
with (0,0,1,1) to get the correct behavior, matching what QRectF does.
QRectF(0,0,1,1).bottomRight() == QPointF(1,1)
QRect(0,0,1,1).bottomRight() == QPoint(0,0)
Reviewed-by: TrustMe
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qpainterpath/tst_qpainterpath.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Each version of Qt has its own set of autotests, therefore
preprocessor directives relating to obsolete QT_VERSION's
are not necessary.
Reviewed-by: Carlos Duclos
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need mouse tracking unless there are items in the
scene that either accept hover events or have a cursor set.
This cut-off is extremely efficient in the common case since
all items ignore hover events and use the standard cursor
by default.
We no longer dig for items and do lots of intersection and
calculating just for fun :-) We even get rid of the overhead
of 2 x QCoreApplication::sendEvent!
The next step is to optimize the items(*) functions to
simply check for hasCursor()/acceptsHoverEvents() before
we do complex checks like intersects/collidesWithPath() etc.
Auto test included.
Reviewed-by: Andreas
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change shows a limitation in Graphics View caused by QPen's
default width being 0 (cosmetic), while Graphics View actually
does not support cosmetic pens at all. Because items are at risk of
drawing lines that poke 1 pixel outside their bounding rect,
QGraphicsView must look for items that are up to one pixel
larger than their bounding rect mapped to viewport coordinates.
Furthermore, mapToScene(QRect) forces us to adjust the
input rectangle by (0, 0, 1, 1), because it uses QRect::bottomRight()
(etc) when mapping the rectangle to a polygon (which is _wrong_). Since
this behavior has been there since 4.2, we don't want to fix it in
a 4.5 patch release...
The only _proper_ fix to this problem is for the view to know the item's
"adjust" in device coordinates, allowing items to use cosmetic pens
freely. Fex, we could introduce QGraphicsItem::viewportMargins() or so.
Added an autotest to ensure this doesn't break again.
Reviewed-by: bnilsen
|
| |
|
