i will look into it next week after my social escapades
On Wed, Mar 5, 2014 at 4:36 AM, i go bananas <hard....@gmail.com> wrote: > >>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.<< > > why do the iem tab objects work so much better then? maelstorm said that > it was incredibly slow using an [until] based counter, but worked smoothly > with the iem objects. This was for EXACTLY the same gui, so i'm not really > sure if it's a gui redraw issue. > > Then again, he also said that the iem tabs objects seem to process tables > in chunks...so maybe the gui is also only redrawn in those chunk sizes? > that would make sense i guess. > > > > > On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner > <billy.stilt...@gmail.com>wrote: > >> "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 >> >> >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list