Yeah, I see you try to handle deleting objects in your code, but the sad fact is, you are overlooking something. In my experience, it is a hash key that is not getting completely removed, or you get auto-vivication in some hashes. But without actually trying to trouble shoot your code, and just from your comment " so every pixel is, unfortunately, a seperate, persistant line segment" , you need to rethink how you draw your lines, so that every pixel IS NOT a new segment.

My first thought would be to create 1 segment for each moving object. Then as it moves and consumes another pixel, reconfigure the original segment to the end points of the collective pixels. If you think about it a bit, you should be able to do this easily, especially if they move vertically.

I encountered a similar problem in Tk Realtime data aquisition, where I was adding many segments to a continuing graph, and the cpu would bog down after awhile. My solution was to use segments up to a point, then write them out as a solid non-updating curve, then start another temporary segment.

So this little project may be just too 'big' for Tk's abilities to handle??

No you are reaching a point where your desire to use straight forward programming techniques is hitting the limit, where you need to start creatively juggling. Just about any language you use, that has a canvas (and canvas items) will be the same. You cannot expect a widget to handle a gazzillion items, as effectively as a few hundred. BUT if you really insist on following your way of thinking, you might want to switch to SDL. SDL dosn't have the notion of line segments to keep track of, In SDL you write something to the screen and forget it and move on. This has advantages in situations like yours, but disadvantages in that there is no way to easily identify and manipulate an existing segment, and if it gets erased from the screen, it's gone.

Just think about an algorithm that you can feed a set of points (pixels) and it will return 2 pixels which are the extreme end points. Then use those 2 points to reconfigure the bot on the update. That way your canvas will only be handling a fixed number of lines at any one time, just making them longer thru a reconfigure. Or if you eventually want to move along curves, use the technique I showed in Tk Realtime data aquisition, and have each bot, after say 100 updates, leave the last 100 points as a solid non-updatable curve, then start another 100 pixel set which is continually updated.

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

In reply to Re^2: Problems with Tk freezing by zentara
in thread Problems with Tk freezing by wulvrine

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.