long version: What's happening is that pd/extended completely
redraws gop object every time it is moved. What it does not do, is
account for its location (front vs. back) in respect to other
objects when doing this. So, for instance if you move a gop that
is behind another object, once it has been moved, it will appear
in front of it which is wrong since that is not an accurate
reflection where in the gl_list it is located. Hence, next time
your entire canvas redraws (which happens inside pd/extended at
various points), suddenly gop will be again behind the other
object. Confusing, no? Pd-l2ork in an attempt to keep gl_list
consistent always ensures that objects remain visually stacked on
top of each other in the gl_list order no matter what operation
you do. In this case, because we have one of the few remaining gui
objects that do not support accelerated displacement (by
accelerated displacement I mean tagging such object's components
in tcl tk and then moving all objects tagged with the word
"selected" together via a single command rather than redrawing
everything), pd-l2ork falls back to the old pd/extended way of
doing things, just like pd/extended do. It does this with one
notable exception and that is to ensure that the redrawn object
remains stacked where it should be (in terms of front/back) it
also redraws the canvas after such a drag because old way of
redrawing does not account properly for the visual order that
pd-l2ork requires. Since your patch has literally a ton of objects
pertaining to ssssad presets, this takes a while, and hence the
slowness. If you, however, put any iemgui object instead of mknob
inside that gop, the thing will be not only fast, but also much
faster than regular pd/extended.