URL:
  <http://gna.org/bugs/?20309>

                 Summary: layer moving: strokemap damage with repeated, fast
layer drags, for large layers
                 Project: MyPaint
            Submitted by: achadwick
            Submitted on: Tue Nov 20 13:16:40 2012
                Severity: 4 - Important
                Priority: 7 - High
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: git master c807c35c
         Planned Release: None
        Operating System: 

    _______________________________________________________

Details:

Moving layers using LayerMoveMode makes a mess of the strokemap if the layer
is very large. To reproduce:

1. Make a huge layer, containing some small distinct strokes which can be
picked using Pick Context ("W"). Ensure that the small strokes can all be
picked, and flash the preview layer correctly and visibly.

2. Move the layer once, and let everything complete. Confirm that stroke
picking still works.

3. Make lots of small incremental layer moves using 2 or 3 separate drags.
Observe that visible image tiles all move as expected.

4. Pick strokes all over until the problem is visible. If this condition has
been triggered for part of the layer, stroke previews will flash in unexpected
places. The 

Expected behaviour after any number of fast, repeated, small layer moves:
strokes are still pickable just as they were before the move(s).

The problem seems to stem from the idle tasks which decompress, slice up, and
recompress the stroke bitmaps' tiles not completing from one drag before the
next one starts. The problem is more frequent with large layers, and possibly
easier to reproduce for large layers when zoomed in to ~100% since updates
will be quicker.

We should force all pending strokemap moves to complete before either a) the
next layer move can start, or b) the next set of queued stroke moves can
start. Since a) might be lengthy, the user deserves fair warning if we go that
way (busy-interactive cursor, perhaps). b) looks best, but could cause lots of
work to be queued.




    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?20309>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Mypaint-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-bugs

Reply via email to