As my project in Classic reaches completion I start converting to X. Initial intention is testing Android, and I want to see that working properly before investing in new IOS devices (currrent ones only run IOS-9).
Initial findings, after converting a small program that transforms (rotate, transpose) a sprite: graphics are way to slow to be practically usable, in live mode as well as downloaded APK file.
Classic poses no problem.
Any thought?
Thanks, Luc
Hi @Luc,
We’re here to help you with converting your project, so happy to help in any way we can.
Not entirely sure what you mean by
Are you using a timer or the canvas gravity to make your sprites move?
Have you tried remixing one of our sample games to see how everything should perform?
1 Like
Thank you for the proposed help! I will be more specific and provide a small example tomorrow to demonstrate my graphics problem.
Hereby I am providing a small testproject that was made in an effort to understand the specifics of converting Classic to X. For Classic, the Classic file test.aia is provided. I see no way to produce a similar file in X, so I have applied the SHARE button, assuming anyone can now access that public project.
Some more testing revealed that the performance problem is in the execution of the blocks, not as much the graphics part.
If you can, please run both versions of this testprogram to see a performance ratio of 6 to 1 in favour of Classic.
There are differences in the programming of the Classic and X version of this test, due to the many conceptual differences between Classic and X, but performance wise these should be in favour of X.
The differences between designing Classic and X projects are vast, and converting an entire project (4 to 5000 blocks) will be a major undertaking. I need to make sure all functions that were essential in my Classic project are also available in X, or can at least be worked around, before deciding to make the investment of converting.
Button “init” puts a green/red sprite against the left side of the screen.
Button “”+22.5°" lets the sprite pivot +22.5° clockwise around the center of the screen.
Button “rpt” continuously pivots the sprite as above in increments of +22.5°
Please note:
- the difference in speed, between Classic and X
- the difference in button “init” behaviour after the sprite is pivoting
Your valuable help will be most appreciated,
Kind regards,
Luc
Classic test.aia (12.7 KB)
Thanks @Luc but I’m quite confused by your last post…
You will have to actually post the link here. Share links are a much faster way of distributing your projects with Thunkable users than having to go though a the download and upload process that was associated with aia files.
I can’t do this until you share you Thunkable X link
Absolutely! Are these the only three essential functions:
here is the link:
https://x.thunkable.com/copy/4ab48d380d9eb3782b292819ea588524
the buttons’ description is only there to describe how to operate the app, nothing to do with essential functions.
essential functions:
Further testing may reveal missing functionality and conceptual differences, which I will mention as soon as I have not been able to solve or work around.
thank you,
Luc
Hi,
I didn’t separately test Canvas speed, but I think that you will be interested in the performance information of Thunkable X
http://droidscript.ru/main/statyi/thunkablex_base11.php
Best regards, Alex
ACtech demo project
Thunkable X Basic Programming Course
Block Reference
Component Reference
Bug tracker
I’m a bit lost here, I can’t read the cyrillic documents…
1 Like
Do you mean that the animations are not smooth and a little buggy?
Because I ran into that issue when I tried to rebuild a material design drawer that I wanted to animate in width. On my iPhones the transition was smooth but on Android it was very bad… I assume it might also be related to processing power but the timer component seems to have bigger problems on Android in general because it worked much better when I just used the “wait” block instead.
I got the impression that the graphics performance is ok, it’s just the execution performance that bothers me at the moment.
I have no experience with X and IOS, my IOS devices are not capable at running IOS 10.
luc
Yeah I also feel that some things are quite heavy loaded / slow on certain devices. For example hiding something on screen start - i barely see it on a newer iPhone but on my android device you often see it flash before it disappears 
Performance problem!
Comparing performance of a typical set of blocks, representative for my project, Classic vs X, classic outperforms X by a factor of 8 to 1. X is currently not workable for me. My Classic project was close to completion, now I got stuck. Can you please look into this issue?
Thank you!
Luc
I agree after translating your comments, but this leaves me wondering why the developers managed to do ok in Classic? Almost 10 times as fast?
I hope the developers pick up my concerns and provide solutions, otherwise with the end of support for Classic, 1000+ hours of development go down the drain.
Luc
Hi,
Which algorithm works 10 times slower on Thuinkable X?
I’m afraid that accelerating Thunkable X by 10 times will not be enough. My calculations show that in order to enter the commercial level, it is necessary to increase productivity by at least 100 times.
2 Likes
Here is the link to a small test-project just in case you want to have a look. The graphics part does hardly consume any processing time, but eg calculating the 2 lines with goniometrics, is responsible for half of it.
The Rotate/Transform function takes anywhere between 200 and 230ms, on a rather slow Samsung Galaxy A5.
This is unworkable.
My Classic project is 4500 blocks and took quite some time to develop. Performance is still at the edge, but workable, given the fact that some of the code measures function execution time as to play tricks to make the app behave as real-time.
link: https://x.thunkable.com/copy/5a78ed8be6a235d64550dd5d6bb7b8c0
Hi Luc,
I think everyone have speed issue and me too. I build block codes on another screen is almost empty. And I copy them to the actual screen I want to build the blocks. Then I change the component names on the actual screen.(It lonely must be low speed process)
But you must saparate your code to many screens. In contrast, you will see the same slow speed amount in your app when you pass to using your app after opening.
Your example uses slow app variable blocks. Replace them with variables from function parameters and see performance.
https://x.thunkable.com/projects/5dfb4da46f355d703869054c/project/properties/designer/
That makes a dramatic difference in performance indeed. In Classic that difference is minimal though.
I’ll start testing again and hope for the best!
thanks,
Luc