A faster way for changing images?

Visuals, audio, animation. Blended, not stirred. If LiveCode is part of your rich media production toolbox, this is the forum for you.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

bn
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4003
Joined: Sun Jan 07, 2007 9:12 pm
Location: Bochum, Germany

Re: A faster way for changing images?

Post by bn » Wed May 04, 2016 12:30 am

Hello Wilhelm,

I took your example of simple mirror and changed it.

The speed is now on a MacBookPro mid 2010 using LC 8 RC1

for
640 x 480 about 150 milliseconds

for
1600 x 1200 about 850 milliseconds

times include final screen update. And I use the old paintCompression trick I learned from you. Here "RLE" saves quite some milliseconds compared to "PNG". This is not as consistent as it used to be.

I am still trying to find patterns of what works best in the LC 8 series.

Code: Select all

local x="eins"

on mouseUp
   put the paintCompression into tOldPCompression
   set the paintCompression to "RLE"
   put the milliseconds into strt
   lock screen; lock messages
   set cursor to watch
   put the imageData of image x into iData
   put the height of img x into theight
   put the width of img x into twidth
   put 4*twidth into re
   put trunc(twidth/2)*4 into tWHalf
 
   put 1 + tWHalf into tStart
   put re into tUntil
   put "" into tCollect
   
   repeat with i = 1 to tHeight
      put byte tStart to tUntil of iData into tRightHalfLine
      repeat with j = tWHalf  to 4 step - 4
         put byte j - 3 to j of tRightHalfLine after tCollect
      end repeat
      put tRightHalfLine after tCollect
      add re to tStart
      add re to tUntil
   end repeat

   set imageData of image x to tCollect
   unlock screen; unlock messages
   put the milliseconds - strt into fld "test"
   set the paintCompression to tOldPCompression
end mouseUp
And yes I agree that certain operations are slower using LC 8, but for many things there are workarounds. Though convolve is a tough one. Tried my beloved arrays to no avail.

Bevore anyone asks: I collect the data putting "after variable tCollect". This is easy and in my experience faster than writing into an existing variable. I tried for this special case(only half the data is changed) to write into the variable of the imageData (iData). It is a tad slower and makes the code more complicated.

Kind regards
Bernd

sanke
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10
Joined: Tue Apr 11, 2006 7:31 pm
Location: Germany
Contact:

Re: A faster way for changing images?

Post by sanke » Thu May 05, 2016 5:13 pm

Hello Bernd,

Thanks for reminding us of "paintcompression" as an important factor in image processing. Livecode Services should pay you 1.000 $ for your reminder. This is the sum they would charge for fixing my problems as they say. I got a mail from them, apparently they had noticed the recent discussion on the dev-list or here.

For the tests with matrix-convolve scripts I decribed in my last post above (May 2) I had already used my old stack "Speedtest Paintcompression" and had set the paintcompression to RLE for both MC 4.6.1 and LC 8 DP 15. The basic speed difference measured under RLE is that LC 8 on the average is 3.5 times slower than MC 4.6.1.

The default settings are, however, RLE for MC 4.6.1 and PNG for LC versions PNG. Using these settings for the tests - comparing "normal" MC 4.6.1 and "normal" LC 8 - the increasing slowness factor would move nearer to 4 times (for the tested convolve scripts with their special structure only, of course).

I do not remember when exactly these different default setting for MC and LC were introduced, probably even with the first versions of Revolution. On the "result" page of my "Speedtest Paintcompression" you can still find the old text:

"Apart from the individual structure of the respective script, the speed of imagedata processing depends on two additional factors:
- to a lesser extent on the engine version (and IDE)
- as a more important factor on the paintcompression"

I had made speed comparisons at that time between MC 2.6.6 and Rev 2.6.1 and 2.81, this would be a clue to find out when I wrote the teststack. At that time it may have been true that "paintcompression" was the "more important factor". Today I am inclined to think that with the rapid development of the new LC 7.x and LC 8.x versions the main factors (plural) causing speed differences could be found in the engine versions and IDE. I also think this it is a "multi-factorial" issue, not easily to be diagnosed in detail and remedied. You mention that " for many things there are workarounds", but I tend to believe the fundamental speed differences of about 3 times between older and recent versions of MC/LC cannot not be overcome only by more intelligent scripting. The individual script can certainly be very much improved, as can be seen by your examples and that of -hh. But when you compare the "relative" performance of that improved scripts between older and younger engine versions, we will most probably find out that the speed differences will remain at least around 3 times.

I am just running tests in my teststack comparing the three "mirror from right"-scripts, you, "-hh" and I have contributed to this forum discussion, and I will do that taking into account the influence of paintcompression. I think I can offer the results on Monday. Presently I am more occupied with family duties.

Regards,

Wilhelm

Post Reply

Return to “Multimedia”