herveus has asked for the wisdom of the Perl Monks concerning the following question:

Howdy!

I have an application that generates a canvas with a large number of items in it. When it is building the canvas, I see it steadily slow down as it adds items. A typical instance may have several thousand items, each with multiple tags.

The bulk of the display is a grid of cells arranged in columns. Each cell can be clicked on to change its state. As implemented, each cell is composed of a number of items all in the same space.

I'm looking to make it more responsive.

I have several ideas that I want to try, but I thought I'd take the lazy approach and ask for any discovered wisdom.

My ideas:

Multiple canvases

Each canvas will contain a smaller number of items. My hope is that messing with items from a smaller list will reduce the time costs for access and update. The total number of items will not change; they will be spread among more containers instead of being piled in one.

No canvas; use frames and buttons

Each button would be small and bear an image. Each column would be a Frame with the Buttons packed on the bottom.

Replace multiple items with single images

I'd have to construct a suitable set of images, but each cell would only add one item instead of three or four as presently done.

Combinations?

I could use multiple canvases with images.

Other considerations

I do want to keep open the possibilities for selecting multiple cells for group actions, either by some variation on shift-click or by dragging a selection rectangle (or a diamond). I see this action as being a different operating mode from normal cell manipulation.

I'm open to pointers to FMs to R; I'll be examining Mastering Perl/Tk as well, for any clues it offers.

yours,
Michael

Replies are listed 'Best First'.
Re: Perl Tk Canvas and buckets of items
by graff (Chancellor) on Aug 21, 2003 at 01:50 UTC
    You could just draw a suitable image that displays the grid of "cells" properly (draw a bunch of rectangles all having the desired width and height, with different colors depending on their initial states), and then use arithmetic on the mouse position to identify which cell was under the mouse when there was a click (or, more carefully, to determine whether the button-down and button-up events were within the same cell, and which cell that was).

    You wouldn't need to use tags at all, if the column and row dimensions are fixed (or at least, a fixed proportion relative to the actual size of the canvas). Just grab the mouse coordinates on the button-down and button-up events, and quantize these wrt the cell width and height to determine which row and column holds the cell. Keep a separate 2-D data array to hold the current state of each cell, and as you update that array according to mouse actions, simply redraw the given rectangle with some suitable color to illustrate the change of state on that cell.

    If you prefer to use images to illustrate the various states of cells (could get a bit noisy, visually, but you can be the judge of that), then presumably the set of states/images is fairly small, and copying a small rectangular image to a given x,y position is not that different from drawing a solid color rectangle at that position.

    update: this made me think about "well, what are tags good for, then?" I think what they are good for are cases where the canvas may contain overlapping objects, and when someone clicks a position occupied by two or more objects, you get to see how many objects are involved, and which ones. But that doesn't seem to apply in your case, so you shouldn't bother with tags.

[reply]
      Howdy!

      Tags let me refer to all the items in a column at once (by giving them a "colX" tag for various values of X). Tags also let me logically group items that are scattered about the canvas.

      In my particular application, the column dimensions are stable (may be user adjustable, but all the same size). The cells will not be all the same height, so "rows" do not exist as a concept (or at best, weakly).

      The set of states/images is fairly small. The display is all visual, so the "noise" is not an issue.

      Thanks for the thoughts, even if I cruelly reject them *grin*

      yours,
      Michael

[reply]
Re: Perl Tk Canvas and buckets of items
by PodMaster (Abbot) on Aug 21, 2003 at 07:27 UTC
    What exactly are you making, some kind of spreadsheet something-or-other? How big does each cell have to be? Having multiple canvases ought to help the "seek time" (for lack of a better term). Frames and buttons will definetly add more overhead. The best solution would be to find a better toolkit, and/or a widget better than canvas.

    update: crazy tk xbm tingy may be a little relevant.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
      Howdy!

      Thanks for the pointer to crazyinsomniac's xbm thingy. I don't yet know if it will help my particular case, but...

      The thing I am making is a Tablet Weaving design tool that shows a visual representation of the outcome that you can edit on the fly. It has something of the spreadsheet character. Each cell will be on the order of eight to ten pixels wide at minimum by anywhere from one to six or more times that height. I'm inclined toward the multiple canvas trick. I can easily pack() them making geometry management relatively simple.

      Given the very graphic nature of the beast, Canvas seems to be an obvious choice. I'm not sure which widget would be "better". I'm kind of fixated on Tk for now, or at least I want to provide that option.

      yours,
      Michael

[reply]

Back to Seekers of Perl Wisdom