Well, a clean up of TriD has been long planned but has been taking a back seat to getting 2D graphics, 64bit support, and NiceSlice.
Ideally, the TriD code would become more independent of the GUI toolkit used, able to interoperate, and easier to see how to extend. I've taking a couple of whacks at it but the architecture is pretty tricky and totally undocumented. I haven't wanted to go further since, at the moment, I think the only way forward would be a complete rewrite. --Chris On Sun, Jan 6, 2013 at 11:42 PM, Craig DeForest <[email protected]> wrote: > Shudder. I just went back and looked at the various evil hacks I used to > get fluxon movies out of PDL::Graphics::TriD. Either Prima or Gnuplot would > probably be a better choice. > > On Jan 6, 2013, at 9:06 PM, MARK BAKER <[email protected]> wrote: > > David > > I was thinking the same thing, I don't think you need all the old "points3d" > to reproduce the the next > $x,$y,$z ... maybe it was something used to make sure every thing was > working, and was forgotten to > be changed ... I have looked at the pointsd3 in a couple different places > in the PDL folders > when trying to figure out where to try the sprite rounding for the points > instead of the big ugly > squares , as well trying to get different size points in the same scene .. > which is in the OpenGL bible ... > I think I may have to do a search to find all the files that are involved > with it ... > > > -Mark > > ________________________________ > From: David Mertens <[email protected]> > To: MARK BAKER <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Sunday, January 6, 2013 7:32 PM > Subject: Re: [Perldl] PDL Ram efficiency > > Mark - > > I ran reproduce your ram troubles with the PDL code that's contained in your > YouTube description. I suspect it has something to do with how one creates > animations using TriD, and that repeatedly calling points3d. Specifically, I > suspect (though haven't dug through the TriD code enough to confirm) that > each time you call points3d, the data gets copied somewhere, and that copy > never gets destroyed. > > Chris, does my explanation sound plausible? > > David > > > On Thu, Jan 3, 2013 at 2:06 PM, MARK BAKER <[email protected]> wrote: > > > here is the pastable text ... Tested it on Ubuntu.. > both work.. posted below > > -Mark > > ________________________________ > From: MARK BAKER <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Thursday, January 3, 2013 8:56 AM > Subject: Re: [Perldl] review of sf.net bugs/features for PDL-2.4.12 > > I Have been noticing a problem with the ram usage with PDL > I wrote some code in PDL then in OpenCL and the OpenCL > code Doesn't use any ram while the PDL code slurps up > about .01 Gigabytes per second , which really starts to add > up ... > > here is the code for both ... > > OpenCL code > > http://www.youtube.com/watch?v=Tm2-YCGvBvo&feature=share&list=UUPHFUHiwbpMqC8ONxEICCiQ > PDL code > > http://www.youtube.com/watch?v=3LXUz_Qez4A&feature=share&list=UUPHFUHiwbpMqC8ONxEICCiQ > > > > --Mark > > > > Given the recent work on plotting libraries, I wonder if you, Craig, Dima, > and I might consider working on stronger support for PDL::Graphics2D? As > your work on the tracker indicates, there are quite a few other subsystems > that could use help, so perhaps we should focus some effort now on those, > and come back to the graphics end later. Furthermore, that'll be a pretty > big project, and I would prefer to hold off until this summer due to tuits > and timing. > > That having been said, if it would work better for you guys to hit that now, > I would be game. :-) > > David > > > On Wed, Jan 2, 2013 at 12:25 PM, Chris Marshall <[email protected]> > wrote: > > I've just completed a review of the PDL Bugs and Feature > Requests tracker items outstanding at > http://sourceforge.net/tracker/?group_id=612&atid=100612 > and > http://sourceforge.net/tracker/?group_id=612&atid=350612 > with an eye to goals for an upcoming PDL release and what > would make a good target. > > I urge PDL users and developers to look over the existing > Bugs and Feature Requests. If any strike your fancy, please > feel free to step up and code. Also, if there is something > you think would be a good/useful addition to PDL, add an > item to the Feature Requests or bring it up on this list. > > Thanks much, > Chris > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
