Same-size chunk replacements (was RunRev vs RealBasic)

[Lynch, Jonathan]

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: use-revolution-bounces at lists.runrev.com
[mailto:use-revolution-bounces at lists.runrev.com] 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
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution