diff options
author | Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com> | 2009-09-28 14:13:19 (GMT) |
---|---|---|
committer | Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com> | 2009-09-29 09:06:41 (GMT) |
commit | e9d63b7824e9105074dee9ad624582e5894d9c8b (patch) | |
tree | e9c2ee4a81d3dafef041c343ce8b5e74645e3964 /src/testlib | |
parent | 5170774f96c87e73f997fb9a9bc856d5f78741ac (diff) | |
download | Qt-e9d63b7824e9105074dee9ad624582e5894d9c8b.zip Qt-e9d63b7824e9105074dee9ad624582e5894d9c8b.tar.gz Qt-e9d63b7824e9105074dee9ad624582e5894d9c8b.tar.bz2 |
QGraphicsItem: cached embedded widget item is not repainted when widget is updated
When calling QGraphicsItem::update() on a cached item, the cache is
meant to be invalidated.
In the reported bug, the user had a fixed scene rect
set for his scene, and removing an item caused the entire scene to be
updated (marked as "all needs to be updated"). In this case, calling
update() on the cached item did not cause the item's cache to be
invalidated. The item's new appearance didn't show up until the next
invalidation, which was the same call to update(), but this time without
a preceeding full scene update.
The fix is to always invalidate the cache, regardless. But only
schedule a repaint of the item in some cases (e.g., in this case the
whole scene was marked for update, in which case it's unnessary for this
one item to schedule a repaint of itself).
It's worth noting that in 4.6, removing an item be delete does not cause
the whole scene to be updated, and because of that this error was not
exposed. It's there nevertheless.
Reviewed-by: bnilsen
Diffstat (limited to 'src/testlib')
0 files changed, 0 insertions, 0 deletions