LiveCode Forums.

I have a stack where the photo (typically 4000x3000 pixels 5mb jpg) is drag and dropped onto the image area and the resulting image in this area is exported to a file. The resulting image is reduced to about 570 pixels for the largest (width or height) dimension.
This process can take up to 25 seconds either in the Livecode environment or as an exe.
This is far to long, even on a very fast pc.
It normally takes just a second to display the original photo in a picture viewer, full screen, so the holdup must be in Livecode somewhere.

Can anyone advise me how this can be improved or is it a failing of Livecode?


Code used:-
on dragDrop
put the dragData["text"]into TmpFileNm
lock screen
if TmpFileNm contains ".jpg" or TmpFileNm contains ".jpeg" or TmpFileNm contains ".bmp" or TmpFileNm contains ".png" then
set the itemDel to "/"
put TmpFileNm into filnam
put the last item of filnam into filnam
set the itemdelimiter to tab
set the filename of image "picture" to TmpFileNm --"Picture"
export image "Picture" to url ("binfile:" & WorkFolder & item 5 of line tSelLine of field "Index" on Card 2) as jpeg
end if
unlock screen
end dragDrop

Happyrever wrote:Code used:-
on dragDrop
put the dragData["text"]into TmpFileNm
lock screen
if TmpFileNm contains ".jpg" or TmpFileNm contains ".jpeg" or TmpFileNm contains ".bmp" or TmpFileNm contains ".png" then
set the itemDel to "/"
put TmpFileNm into filnam
put the last item of filnam into filnam
set the itemdelimiter to tab
set the filename of image "picture" to TmpFileNm --"Picture"
export image "Picture" to url ("binfile:" & WorkFolder & item 5 of line tSelLine of field "Index" on Card 2) as jpeg
end if
unlock screen
end dragDrop

Happyrever, I am trying to figure out how this works. Is this handler in the "picture" image object or someplace else?

-- Mark

I dont think it should take that long, maybe because you are saving it to a file, during the process.

You might try displaying the image first, then lock screen for the image export to take place.
I dont have the rest of your code for the object invoking the handler, but if variable "filnam" is not being used, you could also remove those lines of code. Just a suggestion. Also, you could show a loading indicator after the image is displayed(where mentioned above), while the file is being exported. Then hide it after completion, but you wouldnt be able to use lock screen

Hi Mark
As I said in my message, the handler is in the image, though I cannot see what difference this will make. Is there any?
I also listed the sequence of events, file size as well as the code.
During testing, I put answer "1" etc so I could see how long each stage took.
It was all in the line beginning with export..........

Thank you cbodell for your input.
Whilst I haves an open mind on solutions, I have spent a lot of time and thought producing an interface with the minimum buttons to do the job. The process of drag and drop displays the image, converts it and saves it as well as other housekeeping not shown in the script you have seen. Adding a save button will not make a difference to time, because the file comming in is about 5mb and about 0.70mb out, or saved.
The housekeeping part makes no difference to timings according to testing.

I have found that my older camera produces pictures at 1.8mb compared with the new one at 5mb. It takes about 2 seconds to complete the process with that file size (1.8mb) and about 25 seconds with a 5mb file. They both export at about 0.70mb so the time is related to file size exponentially 2 to the power of 5.
Anyway, the real problem appears to be live code, because basic operating system image handling on mac or pc to a picture viewer is practically instantaneous.

I had hoped there would be a programmer out there who has experience with picture files and a magic live code solution.

What does runrev have to say? I thought version 5 live code was supposed to be many times faster in the graphics rendering department, but perhaps that is something different.

Happeyrever,

The lacking of speed efficiency is mostly in the file size. LiveCode definitely lacks in speed when it comes graphics/images thats a given, especially parsing image data though that is irrelevant to your needs. Though the graphics engine was re-built, there is still some issues that i have noticed in version 5. Still nothing too problematic, which will probably be fixed soon, in future releases, i prefer RunRev pre-4.0.

The reason it is slower than most basic windows image processors or viewer applications is because most of them run at a lower-level language. Closer to the OS Base. C#, C++ etc. LiveCode/RunRev code runs through the engine, first, its own language in a sense, that is why it isn't so efficient in certain categories. Windows image processors are instantaneous because they run on a language similar or same to Windows. Works same way for Mac I believe but different languages. Im not a mac user so i cant say with certainty. LiveCode is preferred by a lot of people for less coding, more efficiency in build-time. Not for speed, or Horsepower.

I mentioned earlier displaying the image, that is drag & dropped before locking screen, and exporting too file. You might try a different save method, try taking the raw imagedata and exporting to file. instead of the export function, as it is based in the livecode engine. It might not give a difference in speed, but it could be worth a try unless you already have, then disregard.

Hope it helped, Good Luck!

Thank you Chris, I will try saving the raw data rather than export.
Lack of speed is a key obstacle for me and has caught me out at the last part of development. In some ways, a change in camera (larger images) has hilighted the problem.