Looks like a winner! The colordex, primary view, and secondary view all update promptly, and adjusting zoom works fine on both of them. Verified also on Chromium.
AFAICS the colordex glitch is not dependent on a particular set of colors, but seems to occur like this:
1. accidentally plot color on the colordex while attempting to set start/end position, turning eg a run of darkblue-purple-pink-white into darkblue-purple-pink-white-darkblue
2. Successfully set start or end position, so that the run encompassed is the aforementioned accidentally-modified one which begins and ends with the same color
3. Script becomes confused and eats a lot of CPU time
4. Firefox becomes enraged and kills script
5. Area of colordex is erased (I'm guessing this is due to the colordex analysis being temporarily destructive to the colordex, and the script being interrupted before it can be restored)
This can probably be largely avoided using the colordex lock, though I guess you probably also want to incorporate a check for the pathological case where a ramp contains a color more than once non-contiguously.
Thanks for the explanation. Yeah, now that I think about it, straight spatial movement wouldn't exactly work because colors are not guaranteed to be unique, even after compressing runs of the same color.
On the generating inbetween colors thing, I guess I'll just go with GIMP's Pencil tool on a colordex export for now, since GIMP accepts color DnD.
« Last Edit: August 15, 2014, 05:53:46 am by Ai »
Logged
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.