<I've thought some about this problem. If you can't use the direct editing
<mode (choose pencil, eraser, etc..), then it will probably be too slow.
<Perhaps a DLL or XCMD would do the trick...
<-Chipp
Thanks, and sorry Chipp, I am not only new to Transcript but I also know
nothing at all about Macs. I presume that an XCMD is the Mac version of a
Windows DLL (?) I am sure that it would help, but I am not sure to what
degree. I have only ever written one DLL in my life which is for the said
eraser program in VB (due to be launched soon). It converts RGB to HSL and
v.v. By doing the calculations in a DLL rather than in the program the
saving was about 15%. Although this 15% was crucial in the eraser routine I
wrote, it was generally a disappointment: I expected a much bigger saving.
But perhaps more important is the fact that I would have a program which was
not truly cross-platform. Apart from the simple elegance of the Transcript
language, the cross-platform aspect is my main attraction. Rather than
regard it as a fixed entity, I would frankly prefer to see the Transcript
language corrected, improved and adequately extended. But I don't suppose
the RunRev team would be listening at the moment as it seems they are
occupied by some other minor task.....
>From Dar Scott:
<I need to read Ken Ray's article. I suspect his examples are designed
<for clarity rather than efficiency.
<Char chunking for getting data is fast. Char chunking for replacing
<data can be slow. Specifically, ...
<Assume operations are on a copy of the image. Char chunking for
<getting pixel data is fast. However, char chunking for replacing pixel
<data goes up with the size of the image. (It might be nice if
<replacement noticed the size was the same and did the replacement in
<place, but alas, that doesn't seem to be the case.) It is thus better
<to replace the entire pixel rather than each individual pixel component
<in an image of nontrivial size. And, as mentioned in #3 below, it is
<better to replace sub-rows than pixels.
<Here are a couple things to try.
<1
<There may be places in which it is better to refer to the image data
<(or sub-image) by reference and refer to parts of it by that and char
<positions.
<2
<There may be ways you can avoid repeating row-column calculations. Use
<a function to create a char pointer from row and column and use that as
<you need. For example, you don't need to calculate the position for
<both the read and the write.
<3
<After you are happy with your method, change the atomic operation from
<pixel orientation to sub-row orientation. This handler should work on
<a sequence of pixels (as specified by char positions) and need not know
<anything about the size of the image. That is, you don't have to do a
<row-column calculation for each pixel and replacement is directly by
<char pointer. If you need a few pixel oriented operators but don't use
<them often, build them out of the sub-row operators. Remember, build
<up your new sub-row, then replace it in one operation. If you prefer a
<functional style, you can use a string function to operate on a an
<sequence of pixels and return a string of pixels and then put things
<together at the higher level. With that optimization, the char
<chunking replacement will be less of a hit; you will be doing only one
<replacement per row under your wand. It the image can be lots taller
<than the wand, you may want to select out the applicable rows, make the
<transformation, then then put it all back together.
Thanks a lot Dar. There's a lot of useful stuff there. But I haven't got to
the bitmap's rows and columns yet. I've just tried to replace the first 400
pixels (first row) of a 657 pixels wide photo, with no calculations on the
pixels at all.
The following little routine is designed simply to replace the first 400
pixels of a photo.
Since I have almost no experience in Transcript, please excuse anything
stupid I may have done.
"bmw.bmp" is a Windows bitmap of 657x319 pixels.
It occupies 614K
on mouseUp
put empty into iData
put binaryEncode("CCCC",0,0,255,0) into redPixel
put the imageData of image "bmw.bmp" into iData
delete char 1 to 1600 of iData
repeat with i = 1 to 400
put redPixel before iData
end repeat
set the imageData of image "bmw.bmp" to iData
play beep
end mouseUp
On my (admittedly humble Pentium II 450hz 128M memory) PC, the above little
routine takes almost 8 seconds to execute!
So what stupid things have I done to make such a modest little routine take
8 whole seconds to execute? I am sure that improvements can be made in the
coding to make it faster (e.g. the repeat bit), but 8 seconds is almost like
a century in computer time!
Any comments on the above routine?
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
