"So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k"
thats why i say fix tcl/tk my old graphics library could be used for a new gui. it is c++ but has the logic to even only update lines as in blit an arbitrary line. On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote: > On 03/04/2014 01:20 PM, Jonathan Wilkes wrote: > > On 03/04/2014 10:11 AM, i go bananas wrote: > > [...] > > >> >> 2014-03-04 12:12 GMT+01:00 i go bananas <hard....@gmail.com>: >> >> just for interest perhaps, here's the sound editor i made years ago: >>> >>> http://puredata.hurleur.com/sujet-1295-sound-editor >>> >>> and probably even more interesting, here is maelstorm's wave display >>> abstraction: >>> >>> http://puredata.hurleur.com/sujet-5890-waveform-display >>> >>> >>> >>> basically, what maelstorm discovered was that using [until] with a >>> counter was not nearly fast enough to do the calculations needed for a >>> decent zoom/scroll function, and we looked into it, and there just didn't >>> seem to be a vanilla workaround. So he uses iem_tab objects to do the >>> table calculations. >>> >> > Remember that when you redraw an element of an array you actually redraw > the _entire_ array in Pd Vanilla. And depending on the array style you may > have a separate tk canvas item for each element. > > So when you use the [until] loop you are sending drawing instructions to > the GUI ($arraysize * $no_mouse_events) times. A single array redraw > instruction in tcl is about 4k, so to scroll a single pixel for a > 100-element array: > 100 elements * 1 = 100 redraws * 4k = 400k > > That's flowing from the core to the GUI for a _single_ mouse event. If > you trigger ten scrolls you're already at 4 megs of data sent. > > I'm pretty sure commercial editors avoid that type of design. In editors > like the upcoming Openshot Video that have several discrete parts that > sending messages, the GUI part almost certainly sends nothing at all to the > video core for zooming/scrolling. For moving a chunk of audio/video, it > almost certainly sends a single message about a single object's delta. > > > I may have showed this already, but I think it's instructive here: > https://jwilkes.nfshost.com/pd-tiger.webm > > I don't have sound on that clip, but I believe I tried it with the "test > audio" patch going and I wasn't getting dropouts. This is because a) I'm > sending a single transform message for every scroll of the number box and > b) the GUI toolkit-- not Pd core-- is doing the math to transform and > redisplay the drawing. > > Socket traffic is bad because it require both the core (sending) and GUI > (receiving) to do work. If you generate megs and megs of traffic you can > end up with dropouts and choking display even if there's very little being > redrawn. > > -Jonathan > > > -Jonathan > > > > > > _______________________________________________pd-l...@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list