Item::scheduleRepaint() invalidates part of an item. It doesn't invalidate the corresponding part of the scene globally. There are a couple of reasons why it works the way it is: - the first, and the main one, is to keep effects like blur working - the second is to cull out invisible repaints, i.e. repaints scheduled by obscured items This kind of repaints is suitable when the size or the position of the item changes. However, it's not good in case the stacking order changes. For example, consider two sibling items: `[A, B]`, `B` is on top of `A`. If the `z` of item `B` is set to `-1`, the effective stacking order will be `[B, A]`, and only repaints for item `B` will be scheduled. When `WorkspaceScene::preparePaintSimpleScreen()` processes the next frame, it will see that item B is occluded by item A, so it will discard item B's repaints and the corresponding graphics buffer will _not_ be repainted even though it should be. In order to prevent that, we need to schedule a global repaint. Is there a less error prone design? Yes, if we could specify the contents of every frame declaratively, then we could diff two consecutive frames without manual meticulous repaint tracking. The magnitude of such changes is beyond a bugfix though.wilder/Plasma/6.3
parent
5133842717
commit
cf6f27be06
2 changed files with 22 additions and 5 deletions
Loading…
Reference in new issue