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:
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)
pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here)