W dniu 28 lipca 2010 18:15 użytkownik bulia byak <buliabyak@...400...> napisał:
2010/7/28 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 28 lipca 2010 06:52 użytkownik bulia byak <buliabyak@...972.....> napisał:
I don't see any necessity for dynamic generation of keys, and doing a string dup on each undo event sounds unnecessarily wasteful.
~50 bytes of extra memory consumption per document looks like a reasonable price to pay to fix undo in the filter dialog, and possible future places that will need to use dynamic generation of undo keys.
Once again: we don't need dynamic generation of keys. Look a fill&stroke: it just flips between two static strings. It's faster and easier.
Here's why we can't use static strings in the filter dialog:
Let's say you have two Color Matrix primitives with type Hue Rotate, adjust one of them, then select the second one and adjust it as well. The two events should not be coalesced, which means they should have different undo keys. Since there is no limit on the number of Color Matrix primitives in a filter, we must generate the undo key string dynamically.
Of course you could hack around it by storing the undo key string in the filter dialog and changing the argument to maybe_done between e.g. "filter:1" and "filter:2" whenever the actual undo key string changes, but doesn't it make more sense to fix the API limitation instead of papering over it?
PS: This might be a small inefficiency, but it uses much simpler code than alternative solutions.
Regards, Krzysztof