| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Several auto-tests failed on the Mac because the view get two paint events on the
first show. This is a bug in QWidget, but shouldn't make graphics view auto-tests
fail. Also, there's no difference between update() and repaint() on the
Mac.
|
| |
|
|
|
|
|
| |
Use QApplication::sendEvent directly instead of calling the static
sendMouseMove function, which also calls QTest::mouseMove. This test failed
with spy.count() being 2 instead of 1 (which is correct since we both use
QTest::mouseMove and QApplication::sendEvent).
|
| |\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem_p.h
tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp
tests/auto/qgraphicsview/tst_qgraphicsview.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch improves the graphics view support for input
methods in several ways:
* A new ItemAcceptsInputMethod flag is introduced to serve
the same purpose for graphics items as WA_InputMethodEnabled
does for widgets: Input method support can be controlled
individually for each item.
* The input method sensitivity of a view (i.e. the value of
the WA_InputMethodEnabled flag) is updated dynamically
whenever the input method support of the current focus
item may change.
* Input contexts are reset whenever an item that supports
input methods loses focus.
Reviewed-by: janarve
Task-number: 254492
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We can do QRect::intersects/contains/operator| faster than QRect
because we can assume the rects are normalized. Another
important factor is our knowledge about the viewport rect, which is
always QRect(0, 0, viewport->width(), viewport->height()).
Auto-tests included.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This test has been broken after 32f32ee3e752a6cc03505ddaa48d2849eaedc2a6,
but the test continued to pass because another bug, which is fixed
by 6ee3fb750377eeedf161d96fef02c5fa336810e9.
The transform should be exactly the same in both cases.
|
| | | |
|
| | | |
|
| |\ \
| |/
| |
| | |
qt-main/qgraphicssceneindex
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Reviewed-by: Trust Me
|
| |\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
qt-main/qgraphicssceneindex
Conflicts:
src/gui/graphicsview/graphicsview.pri
src/gui/graphicsview/qgraphicsitem.cpp
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
qt-main/qgraphicssceneindex
Painfull merge due to recent changes in QGV framework.
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/graphicsview/qgraphicsscene.h
src/gui/graphicsview/qgraphicsscene_p.h
src/gui/graphicsview/qgraphicsview.cpp
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| |/ /
| |
| |
| |
| | |
Now the QGraphicsScene has no idea how works the index. So we can
improve it separatly, add new ones and benchmarks existing ones.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
