Freelss 1.5 update

Can you run a top on your pi and see what its spiking to? I run RPI-Monitor to keep track of CPU and RAM & Swap. I am mostly concerned with swap. One more thing you should probably turn off your desktop on the pi. It frees up the system to an incredible amount.

I suspect your running a pi 1? I can see where it may run out of resources.

Testing my own scanner with the software. So far so good. I also notice WEBGL is behaving better now. With 5MP still mode its initial spike is a bit over 1: then it settles around .6-.8..... I have noticed the memory consumption to be higher though. Around 400MB in total. That could be due to OS updates...... 0% swap though.

adaptedesigns, what do your test images look like in those modes?

Here are more informations in images about what happen :

Boot sequence:

My settings :

Object scanned :

Test image :

And errors message : as you can see, just after the first scan it announced about 10 hours remaining in 1.9M

Switching threshold to 5

Monitoring :

I switch to 5M still mode and change the threshold to 3 because the test picture seems better : all goes wright scanning speed as usual in this mode.

For completeness I made the test including cutting the mouse stand in settings page : doesn't change anything.

@ engineerd3d : 3 hours seems a lot for me, with 1.4 version I get a full scan in 5M still mode of the mouse you can see above in about 1H30. I guess it will depend on the object size.
For me, slow down means that the scan will take about 10 hours in 1.9M thus it takes about 20mn in 1.4 version for the same object/light/hardware and so on.
I guess 1.4 version given me high performance bad habits...

adaptedesigns, what are you using as the base object to hold the mouse?  The laser seems to be scattering on the base object and making it hard for the software to detect the laser's location.  This typically happens when the object is too shiny, the laser threshold settings are too low, or things are moving in the background.  As of FreeLSS 1.5, when this condition is detected the scanner will wait a second and then try again.  The idea is to give things moving in the background time to get out of the camera's view.  It will do this up to 5 times, ie: 5 seconds of simply waiting per frame.  This is likely what's causing your performance issues.  You should be able to resolve this issue by increasing your threshold settings until you don't see the scattered red points at the bottom of the test images or by using a non-reflective object as the base.

I was experiencing the offset like you describe in earlier versions of freelss. I too am getting slowdown now, or at least was getting it. My scaner is misbehaving for reasons other than the software at this point (Read self inflicted)