Same-size chunk replacements (was RunRev vs RealBasic)

Lynch, Jonathan BNZ2 at CDC.GOV
Fri Jan 21 09:47:20 EST 2005

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
[mailto:use-revolution-bounces at] On Behalf Of Richard
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
>> Since the data being inserted is the same length as the data being 
>> removed the handle size doesn't change, allowing the operation to
>> 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
> an image or doing something that needs random access or a change to
> 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
> 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
> 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
> 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:
use-revolution mailing list
use-revolution at

More information about the Use-livecode mailing list