• Dmitry Kazakov's avatar
    Fixed a really tricky bug in walkers · 5ea31706
    Dmitry Kazakov authored
    He-he ;)
    It happened due to the following:
    1) Undo of removeLayer command added a layer and issued setDirty
       for this node
    2) The scheduler calculated the walker for this update and put it
       into the queue
    3) Undo of addLayer command removed one of the layers of the stack,
       leaving the queued walker in a very interesting state.
    The point is that the walker stored a shared pointer to the removed
    node, so it still had access to it and there were no crashes, but its
    behavior was not obvious (read "unpredictable").
    So I extended the meaning of the walker's checksum. Now it depends on
    the graph sequence number as well, so the walker is recalculated when
    he gets to know its data is outdated.
    About Graph Sequence Number.
    Now KisNodeGraphListener maintains an integer which shows current "version"
    of the graph or its "sequence number". This integer is incremented on every
    change made to the graph. So if you have some information about the graph
    which was acquired while the sequence number was X and now you see the number
    equals to Y, you should know your information is outdated and someone has
    changed the graph since then.
kis_async_merger.cpp 12.3 KB