> Well, yes, I have them, but it's not very relevant, as I already know that > those changes make Pd really worse in too many cases. > > The interface common to all item-types has a function to return one > bbox > (bounding-box : x1 y1 x2 y2). It is assumed that the whole bbox has to be > redrawn whenever any aspect of the item has changed. For long > diagonal > lines, this means a damn lot of stuff that isn't even close to the line. > I didn't change this. > > Then this info is centralised as a single bbox that tells which part of > the canvas to redraw. There's only one. In my diff, I replace this by a > grid each representing a 8x8 or 32x32 zone, I don't remember what > precise > size. But that was all, and this caused draw-commands to be duplicated > many times the way I did it, because I drew each zone separately with a > clipmask. There would have been other ways to reduce the waste, some > involving redrawing multiple zones at once in the grid system, and some > involving handling multiple bboxes at once and merging them into > something > that is not a bbox. > > I also had other ideas, such as making items modify the grid instead of > returning a bbox, which would greatly speed up things like diagonal lines > and perhaps pd's arrays (any item in which the bbox has a much greater > area than the item).
I think a lot of this would be alleviated for the most part if not entirely if: 1) pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data) 2) pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here) _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
