| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Before we had almost two identical functions for removing an item from
the scene. There was only minor differences depending on whether the
item was removed from QGraphicsScene::removeItem or from the item's
destructor. Now we have one function that handles both cases just fine.
Reviewed-by: Andreas
|
| |
|
|
|
| |
We don't have to pass optimization flags; we already have a member
variable we can test for painter state protection.
|
| |
|
|
|
|
|
|
|
|
| |
This change introduced an unexpected interdependency for scenes with
items that enable ItemStacksBehindParent, and that contain children
that are transformed. There's a manual test for this, called
clippingAndTransformations, which shows this problem.
The bug has been fixed and this change also includes an autotest that
covers exactly this problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We have to keep the growingItemsBoundingRect up-to-date if there's no
scene rect. The only difference now is that sceneRectChanged will not
be emitted before entering the event-loop, but the documentation
only states it'll be emitted when the scene rect changes, so we
consider it harmless.
Makes tst_QGraphicsView::sceneRect_growing and
tst_QGrahicsScene::sceneRect happy.
Reviewed-by: Andreas
|
| |
|
|
|
|
| |
This patch also contains a bug fix where a child item didn't
update due to a bit not being properly set. No more rendering
artifacts :)
|
| |
|
|
| |
This is a microoptimization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :)
|
| |
|
|
|
|
|
|
|
|
| |
This function works much faster than the last one, but still it can be
much faster. The main expense right now it seems is the transform
calculations, and the item->collidesWithPath call. There's still much
to gain here.
This function does not make use of the BSP tree's fast lookup so it makes
lookups slower in (e.g.) the chip demo.
|
| |
|
|
|
|
|
|
| |
The QStyleOption constructor is expensive, as it allocates a QFont,
a QPalette and a QFontMetrics. By simply reusing a temporary style
option object instead we carve away wasted cycles.
Reviewed-by: Ariya
|
| |
|
|
|
| |
The recursive approach is faster and fits better into the new
scene transform cache we'll do later.
|
| |
|
|
|
|
|
|
|
|
| |
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 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.
|
| |
|
|
|
|
| |
just calculate it top-down.
Reviewed-by: bnilsen
|
| |
|
|
|
|
|
| |
To avoid sorting siblings in real-time, ensure we lazily sort the list
in place when needed.
Reviewed-by: bnilsen
|
| |
|
|
|
|
|
|
|
| |
This time with a recursive approach of processing dirty items. I've kept
the previous approach using a dirty list, but the recursive one is now
the default. Use QT_GV_USE_DIRTY_LIST=1 to swap.
I've also cached the item's device transform in both cases so that we
can re-use it later when drawing the item.
|
| |
|
|
|
|
|
|
|
| |
Now that we have a recursive painting algorithm these types of
optimizations are no longer necessary. In fact they only cause more
problems and clutter up the code unnecessarily. Removing this also
removes extra overhead from moving and transforming items.
Reviewed-by: Lars
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsitem_p.h
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/painting/qtransform.cpp
|
| | |
| |
| |
| |
| | |
Implement specialized (and more efficient versions) of item_helper()
and child_helper() that test for QPointF in the scene.
|
| | |
|
| |
|
