[PD] GUI and DSP

Ivica Ico Bukvic ico at vt.edu
Sun Feb 12 19:23:27 CET 2012


> 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)




More information about the Pd-list mailing list