Dragging sprite lag after 5-10 seconds

[Andweeb]

Hello,

I have a weird issue where sprites that I've set to drag around the screen lag after a short period of time. 

It used to lag immediately, but then read a forum where someone suggested changing the sprites interval HIGHER because if it's low then it could be giving the device a "heart attack" running those codes so quickly so often (the code in the sprites drag property tells the sprite to centre on the users finger as it's dragged). I set the interval to 100 and voila, it runs very smooth.... for a time. 

After 5-10 seconds it slows down again to a laggy grind. Very odd.

Would love to hear some suggestions.

Andrew

[Andweeb]

To add to this, if you turn the screen off (power button lock the phone) and then unlock the phone again the sprites once again run smooth, for a time and then lag again. So technically if I locked and unlocked the phone every 10 seconds my sprites would constantly run smooth, lol.

[SteveJG]

Perhaps not so odd.  App Inventor processes events asynchronously (essential one after another).  How long are you 'dragging' without ever lifting your finger from the screen?  The duration of the drag and the actual code blocks in the drag event probably force the app to do each successive drag introduced by sampling every 100 ms (a 1/10 of a second).   Perhaps increase to 200 or 300 or occasional take one's finger off the screen?

App Inventor graphics are 'slow' compared to Java built apps; this slower behavior, coupled with many commands in a short interval may also consume a lot of memory ( I do not know that for a fact) too.  Locking the phone and then unlocking might clear the memory cue.

So, what to do?   Live with AI's slower graphics and behavior.   Use an even longer sampling interval.   Do not continuously draw...perhaps use a clock to limit continuous drawing.

Time to experiment.  Is this behavior using Companion?  You might compile (create the apk) and see if you get a better response.  Compiled apps run better than on the Companion.

Regards,

Steve

[Taifun]

It would really help if you provided a screenshot of your relevant blocks, so we can see what you are trying to do, and where the problem may be.

Taifun

---

Trying to push the limits of App Inventor! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun. 

[Andweeb]

Attached

[Andweeb]

Thanks Steve for your suggestions. I fiddled with the interval a bit more but not success. You said "Do not continuously draw...perhaps use a clock to limit continuous drawing." - how do I limit the drawing with a clock?

[SteveJG]

I don't think you need a Clock.   I made a 'doodle' app a long time ago and slightly modified it.   Here are the results:

To produce the above, I used a 10x10 green sprite and your code 

with the changes to your code indicated.  The dragged sprite does NOT lag...it goes on forever on my Samsung tablet.    I added a red 'tail' using a Canvas.DrawLine block in the Canvas.Dragged event handler.  The red trail shows where the sprite has been.  The sprite interval is 100 .

How large an image are you moving in Tile2?   Is the image you place in the sprite large 1000 x 1000 pixels perhaps and you display it at perhaps 10 x 10?  If the display is significantly smaller than the actual image, the app is using a lot of processing capacity to continually shrink and redraw the image.

Try the simpler code and see what happens.  Make sure your sprite is 'right - sized', then ask yourself why you used the additional code you posted...it may not be necessary.

Regards,

Steve

[Andweeb]

Good reply, thank you. However I need those extra bit of code because my sprite can be both tapped or dragged and the code is used to differentiate that. The "Holding" bit of code is to get around a bug where if you started dragging over other sprites it would pick them up too and drag them along. Much of my code is actually getting around annoying **** in App Inventor. 

Anyway you asked how big the sprite was? It's actually small but you might be onto something with the resize drawing - the image is actually bigger than it's holder so it does in fact shrink with every draw. I'll resize the image to match the holder and see how that goes. 

[Abraham Getzler]

Do you have collision events firing?

I have had to eliminate them from a drag app

https://docs.google.com/document/d/1AuhZjdMP55Cl9uOrrPG6x_FpZHlPInTaUfEhiwzDUh8/edit?usp=sharing

Because of their bull in a china shop effect.

ABG

[Abraham Getzler]

An extra idea, I haven't tried it though.

Maybe the slowdown is a backlog of sprite drag events that are waiting to fire because

you passed over them with your drag of another sprite, even though they will 

decide to take no action because of your test in the drag block.

This might happen if you have lots of closely spaced sprites (china shop?)

(conjecture).

If all you have are sprite touchDown and touchUp events, you might

be able to capture the dragged sprite component at touchDown time, and 

drag it under control of a Canvas.Dragged event.

(Eliminate all those Sprite.Dragged event blocks)

That might reduce the number of drag events by an order of magnitude.

(Again, I haven't tried this.)

ABG

[Andweeb]

Hey abraham thanks for your useful input, I'll have to take some time to read your paper but it seems you ran into some of the same problems I did. I have tonnes of collision events :) I used code in each collision to make sure the china shop effect didn't happen. However my slowness problem happens even if I drag the sprite and not collide with anything. I'll see how you solved it and see if I can implement it in mine. 

Dragging under control of canvas.dragged - can this be done? :) that's an interesting idea and I'll look into it also.