Re: Atkinson dither algorithm & 'for each' loop
HI All Hoping I'm not teaching my granny to suck eggs ... Here is a great article I remembered reading from a few years ago. It's easy to find on google so you probably know of it ... http://www.tannerhelland.com/4660/dithering-eleven-algorithms-source-code/ In any case his projects and how he writes about them are interesting http://www.tannerhelland.com/programming-directory/ Lagi On 12 October 2017 at 12:05, Peter Reid via use-livecode < use-livecode@lists.runrev.com> wrote: > One note of caution regarding the use of the "repeat for each" loop, > whilst you will get a loop iteration for every value in the collection > (fldhexa3 in your example), you are not guaranteed the order in which they > will occur. This doesn't matter in a lot of cases but does matter when the > sequence is significant. In the case of your example I believe sequence is > critical, otherwise the pixels might appear to be scrambled! > > The following adjusted loop guarantees the sequence at the expense of > speed: > > put 1 into i > repeat for each word theWord in fldhexa3 > put word i of fldhexa3 into theWord > put 00 & theword & theword & theword after tVar2 > add 1 to i > end repeat > > The original "improved" loop reduces the run-time to 25%. However, the > "modified improved" loop only manages to reduce the original run-time to > 50%. > > The suggested loop above takes advantage of the "for each" mechanism to > produce a set of iterations very rapidly but gets slowed by the need to > guarantee sequence. I wonder whether the LC engine could impose strict > sequence more effectively with a variant of the "for each" loop such as > > repeat for each sequenced word x in theCollection > ... > end repeat > > My own tests, comparing the speed of the 4 common repeat loops, imply that > the current "for each" form is hugely faster than the others. I tested > "repeat for each...", "repeat while...", "repeat until...", "repeat > with..." and a simulated "repeat for each sequenced..." forms using a > simple loop body that added lines of text one after another, e.g. > > put empty into tData > repeat with i = 1 to tMaxI > put line i of tList & return after tData > end repeat > > I ran this test for 250,000 iterations for each type of loop, which > produced the following timings: > > Starting test for 250,000 iterations... > repeat for each... 0 mins 0 secs 111 millisecs > repeat while... 0 mins 30 secs 569 millisecs > repeat until... 0 mins 30 secs 379 millisecs > repeat with... 0 mins 30 secs 341 millisecs > repeat for each seq... 0 mins 30 secs 524 millisecs > > As you can see, in this test the "repeat for each..." form was approx. 275 > times faster than the other forms. Also the simulated "repeat for each > sequenced..." form was no faster than the other forms. This shows how > variable the speed will be with the simulated "repeat for each > sequenced...", depending on the details of the loop body. > > If there was a "repeat for each sequenced..." form of loop in LC, any > speed-up could be very beneficial even if the amount of speed-up was only > 10 times faster! > > Cheers > > Peter > -- > Peter Reid > Loughborough, UK > > > On 9 Oct 2017, at 10:18am, use-livecode-requ...@lists.runrev.com wrote: > > > > Message: 12 > > Date: Sat, 7 Oct 2017 15:53:44 +0200 > > From: Malte Pfaff-Brill> > To: use-livecode@lists.runrev.com > > Subject: Re: Atkinson dither algorithm > > Message-ID: <42023b36-0a4e-4251-bb0c-9cd46de55...@derbrill.de> > > Content-Type: text/plain; charset=us-ascii > > > > Hi Al, > > > > I already posted on the forums, but for completeness also here: > > > > a lot can be done by replacing repeat with with repeat for each where > you can. > > > > --repeat with i = 1 to the number of words of fldhexa3 > > -- put 00 & word i of fldhexa3 & word i of fldhexa3 & word i of > fldhexa3 after tVar2 > > --end repeat > > > > repeat for each word theWord in fldhexa3 > > put 00 & theword & theword & theword after tVar2 > > end repeat > > > > > > A sidenode: > > > > I always use strict compile mode, therefore I added the needed variable > declarations and noticed you use startTime as a variablename, which is a > reserved keyword. That is not a good idea. (I noticed, because I managed > to freeze liveCode where I fixed only half of the use of startTime. Booom.) > > > > Cheers, > > > > malte > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Atkinson dither algorithm & 'for each' loop
After reading Mark Waddingham explanation, now i am using a sequential ordered array for this handler. Check this much shorter and faster version: on mouseUp put the millisecs into startTime set the cursor to busy put the alphadata of img "Image" into tAlphaData put the imagedata of img "Image" into tVar put the width of img "Image" into tImageWidth put the height of img "Image" into tImageHeight put the number of chars of tVar into tImgPixels if existence(sb the "ThresholdDither") then put thumbPos of sb the "ThresholdDither" into tThreshold else put 127 into tThreshold end if put numtochar(0) & numtochar(255) & numtochar(255) & numtochar(255) into tWP put numtochar(0) & numtochar(0) & numtochar(0) & numtochar(0) into tBP put ((tImageWidth * tImageHeight) - tImageWidth) into tHW put ImgToArrayNum(ImgToCh(tVar,1)) into tArray2 put 0 into tPixelCounter put tImgPixels/4 into tPixels repeat tPixels add 1 to tPixelCounter put tPixelCounter into tPixelPosition put tArray2[tPixelCounter] into tOldPixelValue if round(tOldPixelValue) <= tThreshold then put 0 into tNewPixelValue put tBP after fldhexa8 else put 255 into tNewPixelValue put tWP after fldhexa8 end if put (tOldPixelValue - tNewPixelValue)/8 into tDifusionError -- Atkinson dither add the diffusion error -- to 6 adjacent pixels -- x o o -- o o o -- o if tPixelPosition mod tImageWidth <> 0 then -- pixel position is less than image width put tPixelCounter + 1 into tNewKey put (tDifusionError) + tArray2[tNewKey] into tArray2[tNewKey] if tPixelPosition mod (tImageWidth - 1) <> 0 then -- pixel position is less than image width - 1 put tPixelCounter + 2 into tNewKey put tDifusionError + tArray2[tNewKey] into tArray2[tNewKey] end if end if if tPixelPosition <= tHW then -- ((tImageWidth * tImageHeight) - tImageWidth) -- pixel position is not in the last line of the image if tPixelPosition mod tImageWidth <> 1 then -- pixel position is not the first pixel in any line of the image put (tPixelPosition + tImageWidth - 1) into tNewKey put (tDifusionError) + tArray2[tNewKey] into tArray2[tNewKey] end if put (tPixelPosition + tImageWidth) into tNewKey put (tDifusionError) + tArray2[tNewKey] into tArray2[tNewKey] if tPixelPosition mod tImageWidth <> 0 then -- pixel position is less than image width put (tPixelPosition + tImageWidth + 1) into tNewKey put (tDifusionError) + tArray2[tNewKey] into tArray2[tNewKey] end if if tPixelPosition <= (tImageWidth * tImageHeight) - (tImageWidth * 2) then -- pixel position is less than image width - 1 put (tPixelPosition + tImageWidth * 2) into tNewKey put (tDifusionError) + tArray2[tNewKey] into tArray2[tNewKey] end if end if end repeat create img set the height of it to the height of img "Image" set the width of it to the width of img "Image" set the imagedata of it to fldhexa8 set the alphaData of it to tAlphaData put the millisecs - startTime && "milliseconds to create Atkinson Dither from image's single channel" end mouseUp Function ImgToArrayNum vImageData -- This function converts binary imagedata to -- integer numbers from 0 to 255 into -- an array. -- vImageData is a single color channel -- stored as binary imagedata. put empty into tResult put 0 into tCounter repeat for each char K in vImageData add 1 to tCounter put chartonum(K) into tResult[tCounter] end repeat return tResult end ImgToArrayNum Function ImgToCh tImageData tChannel -- This function returns binary data. -- -- tImageData is unmodified original imagedata of image -- with 4 chars for each pixel: 1 alphadata and 3 color channels. -- -- tChannel is a number from 1 to 3: -- 1 is red channel, 2 is green channel and 3 is blue channel put tImageData into tempVar delete char 1 to tChannel of tempVar -- the first char of the imagedata is part -- of the alphadata or maskdata, so when -- we delete char 1, the next char is part -- from red channel... if we delete 2 first -- chars, then next char is green channel -- if we delete 3 first chars, then we get -- the blue channel repeat until tempVar is empty put char 1 of tempVar after tResult delete char 1 to 4 of tempVar end repeat return tResult end ImgToCh Have a nice weekend! Al ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
Re: Atkinson dither algorithm & 'for each' loop
@Al. For multiples of 1/8 (Atkinson) you need 8*256=2048 integers, that is 11 Bit. For multiples of 1/16 (Floyd-Steinberg) you need 16*256=4096 integers, that is 12 Bit. In 2 chars = 16 Bit fit even multiples of 1/256. No dither-algorithm uses such tiny diffusion-errors. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Atkinson dither algorithm & 'for each' loop
Hi Hermann, Hermann Hoch wrote: > So all considerations to improve the LCS script are, > TMHO, of rather theoretical value. Here are some more: > The Atkinson algorithm uses multiples of 1/8 = 0.125 for > the diffusion-error, the Floyd-Steinberg algorithm uses > multiples of 1/16 = 0.0625. > And have this in mind: > Whenever you use numToChar(Number) in your script you > are wrong by Number - round(Number) of the accumulated > pixel value ... This is correct, for this reason, in the most recent version of this handler, I am using 2 chars to store the new pixel value. first char is a whole number from 0 to 255 and the second char represent a decimal part from 0 to 99. I will test if using 5 chars for storing the new pixel value. In this way, the new pixel could store values of .00 that should be enough for this task... After reading Mark's answer, I learned that using a numerical ordered array to store pixel values could be really fast too. This is another path to explore. Al ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Atkinson dither algorithm & 'for each' loop
> Al wrote: > Please, check this new handler in the forum and suggest how to > make this faster and more precise. I already gave you a method that is, with a 500x500 image, at least 1000 (thousand) times faster than your script. Of course this is not due my special skills but the ability of javascript (used via a browser widget) to let the GPU/graphic card do the essential job of pixel manipulation. So all considerations to improve the LCS script are, TMHO, of rather theoretical value. Here are some more: > Al wrote: > ... the result STILL is not visually identical to that handler. > My educated guess is that Atkinson dither algorithm requires > numbers with more than 2 numbers after the decimal point. > That is: 243.643578 instead of just 243.64 Conclude from the following: The Atkinson algorithm uses multiples of 1/8 = 0.125 for the diffusion-error, the Floyd-Steinberg algorithm uses multiples of 1/16 = 0.0625. And have this in mind: Whenever you use numToChar(Number) in your script you are wrong by Number - round(Number) of the accumulated pixel value ... ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Atkinson dither algorithm & 'for each' loop
On 2017-10-12 19:35, Alejandro Tejada via use-livecode wrote: Peter Read wrote: One note of caution regarding the use of the "repeat for each" loop, whilst you will get a loop iteration for every value in the collection (fldhexa3 in your example), you are not guaranteed the order in which they will occur. This doesn't matter in a lot of cases but does matter when the sequence is significant. In the case of your example I believe sequence is critical, otherwise the pixels might appear to be scrambled! Prior to 7, you had to be careful not to modify either the container being iterated over *or* the var holding the chunk for the current iteration as it could cause issues as described (actually, it was fundamentally unsafe to do that, as it could result in a crash). i.e. repeat for each item tItem in tContainer replace "Foo" with "B" in tContainer -- BAD - MIGHT CAUSE PROBLEMS put "a' into char 2 of tItem -- BAD - MIGHT CAUSE PROBLEMS end repeat From 7 onwards, this is no longer the case. You can do whatever you want with either the container. Indeed, in 7, the engine essentially operates as if it was iterating over a copy of the container and with a copy of the chunk (i.e. tItem and tContainer in the above snippet). Upshot - you can do whatever you want with your variables - the engine ensures that what you do won't affect what you asked for to begin with (in particular, if you asked to iterate over tContainer, then it will iterate over tContainer as it was at the point you first asked - any changes to tContainer after the initial repeat for each line will have no effect on the repeat for each clause). Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Atkinson dither algorithm & 'for each' loop
A few hours ago, I send a message to the mail list, a message that vanish without trace. Now I am resending parts of that message. The rest of the message is in the forum... Peter Read wrote: > One note of caution regarding the use of the "repeat for each" loop, > whilst you will get a loop iteration for every value in the collection > (fldhexa3 in your example), you are not guaranteed the order in > which they will occur. This doesn't matter in a lot of cases but > does matter when the sequence is significant. In the case of your > example I believe sequence is critical, otherwise the pixels might > appear to be scrambled! In my own setup, the control structure "repeat for each" is caching the content of the working variable. This means that we could not modify the content of this variable while the control structure is working with it. After reading your message, now I understand why this happens. If developers are allowed to modify a variable used by a control structure like "repeat for each" then we could get unexpected result as you describe: elements are processed in an out of order sequence. Ben Rubinstein wrote in response to Peter Reid: > Are you sure? My understanding has always been that > chunk items, e.g. > repeat for each [ byte | char | word | item | line] in > will always be sequential (indeed that's why this structure is fast) > - it's only when dealing with hashed arrays that the sequence is > not reliable, i.e. > repeat for each key in > repeat for each element in > Do you have experience to the contrary? As I wrote earlier in this same message, Peter could have found some way to change the working variable in a repeat for each control structure and the result is that elements are processed with an out of order sequence. By the way, after reading all comments and recommendations about the atkinson dither algorithm, I wrote a new handler that is a lot faster that my first handler, but the result STILL is not visually identical to that handler. My educated guess is that Atkinson dither algorithm requires numbers with more than 2 numbers after the decimal point. That is: 243.643578 instead of just 243.64 Later this week, I will try to discover the minimal number of decimal numbers that this algorithm requires. Please, check this new handler in the forum and suggest how to make this faster and more precise: https://forums.livecode.com/viewtopic.php?f=10=159078=b46bc56428cb5b0f48d2c6520c107c47#p159078 Have a nice week! Al ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Atkinson dither algorithm & 'for each' loop
Peter Reid wrote: > One note of caution regarding the use of the "repeat for each" loop, > whilst you will get a loop iteration for every value in the collection > (fldhexa3 in your example), you are not guaranteed the order in which > they will occur. Maybe I misunderstand, but are you thinking of arrays there? With string containers a "repeat for each" expression should parse from beginning to end, sequentially. Any exception to that would be prohibitively unpredictable, and should be reported as a bug. > The following adjusted loop guarantees the sequence at the expense of > speed: > > put 1 into i > repeat for each word theWord in fldhexa3 > put word i of fldhexa3 into theWord The speed lost there appears to be the result of a redundancy, and a particularly expensive one: We love the convenience of chunk expressions, but in loops we want to remain mindful of " of " because satisfying such expressions will require the engine to start from the beginning of the container, examine every character and counting delimiters, until it reaches the number of such delimiters specified in "". So the "repeat" line above parses the chunk value into theWord, but then the next line ignores that that's already happened and reassigns the same theWord value using an expression that requires then engine to count words from the beginning of fldhexa3 each time through the loop. With this specific algo I believe there may be further benefits in using a chunk type other than word (based on a a hunch derived from word chunks being parsed more flexibly than items or lines), and perhaps not converting the binary data to hex at all, instead parsing bytes directly with a "step 4" option in the loop to keep track of the four components that define each pixel. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Atkinson dither algorithm & 'for each' loop
That is correct Ben. It's not the repeat for each that is unreliable (probably a bad word to use here) but it is arrays which do not retain the sequence of key/values in the order they were put in. To get around this, when possible use numbered keys, then: put the keys of aMyArray into tKeyList sort the lines of tKeyList numeric ascending repeat for each line tKey in tKeyList ... Bob S > On Oct 12, 2017, at 04:48 , Ben Rubinstein via use-livecode >wrote: > > Hi Peter, > >> One note of caution regarding the use of the "repeat for each" loop, whilst >> you will get a loop iteration for every value in the collection >> (fldhexa3 in your example), you are not guaranteed the order in which they >> will occur. > > Are you sure? My understanding has always been that chunk items, e.g. > repeat for each [ byte | char | word | item | line] in > > will always be sequential (indeed that's why this structure is fast) - it's > only when dealing with hashed arrays that the sequence is not reliable, i.e. > repeat for each key in > repeat for each element in > > Do you have experience to the contrary? > > best regards, > > Ben ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Atkinson dither algorithm & 'for each' loop
Hi Peter, One note of caution regarding the use of the "repeat for each" loop, whilst you will get a loop iteration for every value in the collection (fldhexa3 in your example), you are not guaranteed the order in which they will occur. Are you sure? My understanding has always been that chunk items, e.g. repeat for each [ byte | char | word | item | line] in will always be sequential (indeed that's why this structure is fast) - it's only when dealing with hashed arrays that the sequence is not reliable, i.e. repeat for each key in repeat for each element in Do you have experience to the contrary? best regards, Ben On 12/10/2017 12:05, Peter Reid via use-livecode wrote: One note of caution regarding the use of the "repeat for each" loop, whilst you will get a loop iteration for every value in the collection (fldhexa3 in your example), you are not guaranteed the order in which they will occur. This doesn't matter in a lot of cases but does matter when the sequence is significant. In the case of your example I believe sequence is critical, otherwise the pixels might appear to be scrambled! The following adjusted loop guarantees the sequence at the expense of speed: put 1 into i repeat for each word theWord in fldhexa3 put word i of fldhexa3 into theWord put 00 & theword & theword & theword after tVar2 add 1 to i end repeat The original "improved" loop reduces the run-time to 25%. However, the "modified improved" loop only manages to reduce the original run-time to 50%. The suggested loop above takes advantage of the "for each" mechanism to produce a set of iterations very rapidly but gets slowed by the need to guarantee sequence. I wonder whether the LC engine could impose strict sequence more effectively with a variant of the "for each" loop such as repeat for each sequenced word x in theCollection ... end repeat My own tests, comparing the speed of the 4 common repeat loops, imply that the current "for each" form is hugely faster than the others. I tested "repeat for each...", "repeat while...", "repeat until...", "repeat with..." and a simulated "repeat for each sequenced..." forms using a simple loop body that added lines of text one after another, e.g. put empty into tData repeat with i = 1 to tMaxI put line i of tList & return after tData end repeat I ran this test for 250,000 iterations for each type of loop, which produced the following timings: Starting test for 250,000 iterations... repeat for each... 0 mins 0 secs 111 millisecs repeat while... 0 mins 30 secs 569 millisecs repeat until... 0 mins 30 secs 379 millisecs repeat with... 0 mins 30 secs 341 millisecs repeat for each seq... 0 mins 30 secs 524 millisecs As you can see, in this test the "repeat for each..." form was approx. 275 times faster than the other forms. Also the simulated "repeat for each sequenced..." form was no faster than the other forms. This shows how variable the speed will be with the simulated "repeat for each sequenced...", depending on the details of the loop body. If there was a "repeat for each sequenced..." form of loop in LC, any speed-up could be very beneficial even if the amount of speed-up was only 10 times faster! Cheers Peter -- Peter Reid Loughborough, UK On 9 Oct 2017, at 10:18am, use-livecode-requ...@lists.runrev.com wrote: Message: 12 Date: Sat, 7 Oct 2017 15:53:44 +0200 From: Malte Pfaff-BrillTo: use-livecode@lists.runrev.com Subject: Re: Atkinson dither algorithm Message-ID: <42023b36-0a4e-4251-bb0c-9cd46de55...@derbrill.de> Content-Type: text/plain; charset=us-ascii Hi Al, I already posted on the forums, but for completeness also here: a lot can be done by replacing repeat with with repeat for each where you can. --repeat with i = 1 to the number of words of fldhexa3 -- put 00 & word i of fldhexa3 & word i of fldhexa3 & word i of fldhexa3 after tVar2 --end repeat repeat for each word theWord in fldhexa3 put 00 & theword & theword & theword after tVar2 end repeat A sidenode: I always use strict compile mode, therefore I added the needed variable declarations and noticed you use startTime as a variablename, which is a reserved keyword. That is not a good idea. (I noticed, because I managed to freeze liveCode where I fixed only half of the use of startTime. Booom.) Cheers, malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Atkinson dither algorithm & 'for each' loop
One note of caution regarding the use of the "repeat for each" loop, whilst you will get a loop iteration for every value in the collection (fldhexa3 in your example), you are not guaranteed the order in which they will occur. This doesn't matter in a lot of cases but does matter when the sequence is significant. In the case of your example I believe sequence is critical, otherwise the pixels might appear to be scrambled! The following adjusted loop guarantees the sequence at the expense of speed: put 1 into i repeat for each word theWord in fldhexa3 put word i of fldhexa3 into theWord put 00 & theword & theword & theword after tVar2 add 1 to i end repeat The original "improved" loop reduces the run-time to 25%. However, the "modified improved" loop only manages to reduce the original run-time to 50%. The suggested loop above takes advantage of the "for each" mechanism to produce a set of iterations very rapidly but gets slowed by the need to guarantee sequence. I wonder whether the LC engine could impose strict sequence more effectively with a variant of the "for each" loop such as repeat for each sequenced word x in theCollection ... end repeat My own tests, comparing the speed of the 4 common repeat loops, imply that the current "for each" form is hugely faster than the others. I tested "repeat for each...", "repeat while...", "repeat until...", "repeat with..." and a simulated "repeat for each sequenced..." forms using a simple loop body that added lines of text one after another, e.g. put empty into tData repeat with i = 1 to tMaxI put line i of tList & return after tData end repeat I ran this test for 250,000 iterations for each type of loop, which produced the following timings: Starting test for 250,000 iterations... repeat for each... 0 mins 0 secs 111 millisecs repeat while... 0 mins 30 secs 569 millisecs repeat until... 0 mins 30 secs 379 millisecs repeat with... 0 mins 30 secs 341 millisecs repeat for each seq... 0 mins 30 secs 524 millisecs As you can see, in this test the "repeat for each..." form was approx. 275 times faster than the other forms. Also the simulated "repeat for each sequenced..." form was no faster than the other forms. This shows how variable the speed will be with the simulated "repeat for each sequenced...", depending on the details of the loop body. If there was a "repeat for each sequenced..." form of loop in LC, any speed-up could be very beneficial even if the amount of speed-up was only 10 times faster! Cheers Peter -- Peter Reid Loughborough, UK > On 9 Oct 2017, at 10:18am, use-livecode-requ...@lists.runrev.com wrote: > > Message: 12 > Date: Sat, 7 Oct 2017 15:53:44 +0200 > From: Malte Pfaff-Brill> To: use-livecode@lists.runrev.com > Subject: Re: Atkinson dither algorithm > Message-ID: <42023b36-0a4e-4251-bb0c-9cd46de55...@derbrill.de> > Content-Type: text/plain; charset=us-ascii > > Hi Al, > > I already posted on the forums, but for completeness also here: > > a lot can be done by replacing repeat with with repeat for each where you can. > > --repeat with i = 1 to the number of words of fldhexa3 > -- put 00 & word i of fldhexa3 & word i of fldhexa3 & word i of > fldhexa3 after tVar2 > --end repeat > > repeat for each word theWord in fldhexa3 > put 00 & theword & theword & theword after tVar2 > end repeat > > > A sidenode: > > I always use strict compile mode, therefore I added the needed variable > declarations and noticed you use startTime as a variablename, which is a > reserved keyword. That is not a good idea. (I noticed, because I managed to > freeze liveCode where I fixed only half of the use of startTime. Booom.) > > Cheers, > > malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode