I am interested in creating a 3D object viewer - and I was planning to write it in transcript.
I have been researching the equations, and thinking about everything I can do to minimize processor time, including some schemes that would increase memory usage, but reduce computations. If I had to, I could write the math parts in VB, and try to create an external - but I would rather not. VB drives me nuts. This is just something I work on periodically, so at my present rate it would probably take me a number of months to get it done. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Gaskin Sent: Thursday, January 20, 2005 6:26 PM To: How to use Revolution Subject: Re: Same-size chunk replacements (was RunRev vs RealBasic) Dar Scott wrote: > > On Jan 19, 2005, at 11:33 PM, Richard Gaskin wrote: > >> > I did write some compositing and blur/sharpen filters in >> > transcript some time ago, but I don't know the details of >> > the 'same-size chunk' replacements. Where can I find more info? >> >> All I know is what Dar posted here, but it sounded really tasty. >> Apparently he made a suggestion to Scott Raney about ways to optimize >> operations in which a string of a given length is used to replace a >> substring of the same length within a larger chunk. >> >> In previous versions a very generalized approach was used for all >> replacement operations, requiring that the data be copied during the >> replacement, which can be computationally expensive with large chunks. >> >> Since the data being inserted is the same length as the data being >> removed the handle size doesn't change, allowing the operation to work >> in-place, without copying. >> >> IIRC, Raney reported that the new method should improve speed by >> roughly 4000 times for those cases. >> >> Dar - got the details for us? > > > You got the important parts. > > For building a large string such as an image, the put-after command is > fastest (1 or 2 microseconds on my Mac). So, if you are doing color > shifting on an image, that is the best to go. > > put newPixel after imageSoFar > > But if you are putting a small image over a large image or drawing onto > an image or doing something that needs random access or a change to only > part, then use same-size put-into (6 microseconds on my Mac). > > put newPixel into char p to p+3 of imageSoFar > > This used to take very long on large images. Now both of these are > small fixed time. (Well, there is a tiny growth time every once in a > while for 'after' but it is only a microsecond on my computer, that is, > it is fixed, too.) > > Anyway, use 'after' if you can, and make sure the chunk sizes match if > you can't. > > This also very handy for binary arrays and matrices and such. > > I thought I had entered that as an enhancement into bugzilla, but either > I goofed or it was changed. > > This is one of those things in which a fundamental enhancement or > performance improvement might open the doors to a scripting solution to > what is on folks' wish lists. Good info, thanks Dar. Chipp, does any of this apply to your image processing routines? Anyone else here interested in seeing if it's now feasible to write efficient image filters in native Transcript? -- Richard Gaskin Fourth World Media Corporation __________________________________________________ Rev tools and more: http://www.fourthworld.com/rev _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
