| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem_p.h
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have some nice cut-offs when there's a full update pending, but we
don't know about it if we call update() directly on the viewport.
Instead call QGraphicsViewPrivate::updateAll() which has the same
effect, except that it also sets a flag telling us a full update is
pending.
Reviewed-by: Andreas
|
| |
| |
| |
| |
| |
| | |
See also: 32f32ee3e752a6cc03505ddaa48d2849eaedc2a6
Reviewed-by: Andreas
|
| |
| |
| |
| | |
private class member.
|
| |
| |
| |
| |
| |
| | |
interested in touch events
this is a continuation of 0218d8f8dc569db9a1290f595a814c3690c1b14b
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the API for these 2 classes is identical, the implementation is almost
identical, they share the same data structures, so bite the bullet and
merge them.
this means we go back to using screenPos() instead of globalPos()
again
|
|\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsitem_p.h
src/gui/graphicsview/qgraphicsscene_p.h
|
| |
| |
| |
| |
| | |
We don't have to pass optimization flags; we already have a member
variable we can test for painter state protection.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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 reapply commit 8ad5020940f10d4ecc5c5e8b3b9656531cb84ef3 and its
dependent change that has been reverted while rebasing the
recursivepaint branch.
With the new properties it is possible to easily animate transformations
Reviewed-by: Andreas
Documentation still need to be reviewed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Once a _q_processDirtyItems call is queued, it means we at least have
one item that is marked as dirty and we must reset it when the
_q_processDirtyItems slot is called. The problem however, was that
we didn't reset the item's dirty state if a full scene update occurred
in between, i.e. item->update(); scene.update();
We don't have to calculate the item's dirty rect if a full scene update
occurs in between, but we still have to reset its state.
Auto-test included.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Calling repaint() instead of update() is bad when having multiple
views (which GV perfectly supports). The result is that e.g. when
moving a chip in the chip demo, there's a visible lag between
each view. It can also be a performance killer on QWS, where
the surface is locked for each repaint().
Instead of calling repaint() we call update() as before, but we also
make sure the updates are processed immediately.
|
| |
| |
| |
| |
| | |
Ensure that we don't ask for or multiply with the view transform if the
view is not transformed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Invalidating the scene transform is just a matter of setting a bit on
the item. Then, when we ask for the item's scene transform, we
traverse its ancestors recursively and find the top-most dirty item.
The algorithm then backtracks to that item and start calculating the scene
transform for the item itself and all its children in the call stack.
If the item itself and all its ancestors are "clean", nothing is
calculated, only traversed.
We use this approach when processing dirty items / drawing items
as well. That way we ensure the scene transform is only calculated
once when absolutely needed.
G'night :)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Mark the children list for sorting when the Z value for items changes.
Change the signature of the recursive draw function slightly so that
the expose region is optional, and ensure we don't intersect with this
region if it's not available.
This change also flips the direct painting so that the default is to
use the recursive approach.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change introduces two helper functions in QGraphicsItemPrivate,
that combine the item's transform into the current transform, effectively
merging the code that calculates any item's combined to-parent transform.
This makes the code more readable, and also makes it easier for us to
reintroduce the componentized transform API in QGraphicsItem (which
was previously reverted).
|
| |
| |
| |
| |
| |
| | |
This change also changes the direct painting path to be opt-in as a
temporary testing measure to see what's broken when using the old code
path.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Convert some repaint() calls back to updates(). This ensures that any
updates triggered before this call are processed normally, while still
keeping the synchronous repaint() call intact.
Reviewed-by: bnilsen
|
| | |
|
| |
| |
| |
| |
| | |
This seems to be the only way to get a high frame rate, regardless
of the performance of painting and all.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Since the transform is now a pointer in QGraphicsItemPrivate, we can
use this pointer directly and there's no need for a separate bitflag
anymore.
Reviewed-by: Andreas
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is work-in-progress, so don't expect everything to work perfectly.
Most of the auto-test pass and examples and demos seem to run fine.
Unfortunately I'm too tired to write about the actual update mehanism
now, but it's faster than the old approach (if that helps:)). There's
more to optimize, but I'll come back to that later. I need some sleep now :)
To be continued.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
the important thing is by effectively implementing Simple Canvas' approach
to drawing, we're in theory (and in practise measured on the desktop)
as fast as Simple Canvas when rendering.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Don't have QGraphicsSceneTouchEvent::TouchPoint inherit from
QTouchEvent::TouchPoint. The only reason to do this is to support an
implementation trick, which can be done another way (see below). This
means we have to essentially duplicate the API in the GraphicsScene
variant.
2. Don't use a list of pointers to touch points in QTouchEvent and
QGraphicsSceneTouchEvent. This means we have to make the TouchPoint
classes implicitly shared (and the effect of the previous trick of
static_casting the widget touch point to a graphics-scene touch point
can be emulated by sharing the d-pointers between the classes).
3. QEvent::RawTouch isn't really an event type, it's a
backdoor. Remove it and export the bool
qt_translateRawTouchEvent(QList<QTouchEvent::TouchPoint>, QWidget *)
function instead.
4. Rename QTouchEvent::TouchPoint::area() to size() (which is more
clear as to what the function
returns). QGraphicsSceneTouchEvent::TouchPoint gains size(),
sceneSize(), and screenSize() functions (the actual translation from
screen to scene to item still needs to be implemented).
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Reviewed-by: Lars
|
| |
| |
| |
| |
| |
| | |
screenPos
Reviewed-By: Bradley T. Hughes
|
| |
| |
| |
| | |
Reviewed-By: Bradley T. Hughes
|
|\ \
| |/
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qcoreevent.h
src/gui/graphicsview/qgraphicsitem_p.h
|
| |
| |
| |
| |
| |
| |
| | |
Wherever I found that we were using a string instead of a single char
I fixed the code.
Reviewed-by: olivier
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
QGraphicsProxyWidgets.
This is still work-in-progress.
|
|\ \ \
| |/ /
|/| /
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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:
tools/macdeployqt/shared/shared.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
QGraphicsItem::deviceTransform() returns the item-to-device transform,
provided with the device-to-scene transform, and combining it with the
item's scene transform. This function is meant to handle items that
enable ItemIgnoresTransformations, but it happened to not work properly
for items that _don't_ enable that flag. Unfortunately this bug is
hard to work around for users from the outside, as it requires you to
check if the item or any ancestor enables ItemIgnoresTransformations.
The fix also removes unnecessary branchs inside QGV so that we use the
same function for all items.
Reviewed-by: bnilsen
|
|\ \ \
| |/ / |
|
| |\ \
| | |/
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This required a larger change to the kernel and graphicsview directories to
make this as efficient as possible:
1. QTouchEvent::TouchPoint becomes the base for
QGraphicsSceneTouchEvent::TouchPoint - this means there is one private for
every touch point, and we can store both the screen and scene coordinates
in one place. Converting a QTouchEvent to QGraphicsSceneTouchEvent becomes
nothing more than casting the QTouchEvent::TouchPoints to
QGraphicsSceneTouchEvent::TouchPoints.
2. The logic that we use in QApplication to convert WM_TOUCH* messages to
QTouchEvents is essentially duplicated (with some minor changes) to
QGraphicsScene so that it can support mulitple touch item targets. I
will have to investigate how I can perhaps merge some of the duplicated
code.
QEvent::GraphicsSceneTouchBegin propagation is not implemented yet, and will
come in a later commit
|
| | |
| | |
| | |
| | |
| | | |
QGraphicsSceneGestureEvent to a viewport, so that the user could
subscribe to gestures in a viewport as well.
|
| | |
| | |
| | |
| | |
| | | |
providing some additional info (like a widget that received a gesture
- for coordinates conversions).
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
events.
Details: Copying the QEvent::spontaneous() flag from the received
event to QGraphicsSceneEvent.
|