Good news, and not so good news.Ref moving to Graphics 2 Compatibility Mode =1
I have just tried Version 2014.2189 (2014.3.6) with just graphicsCompatibility = 1, – Turn on V1 Compatibility Mode.
{Rob, should I just use your mention Special build 1262- I just downloaded the latest build on the web?}
NOTE: I am testing a fully working publishable app that runs as required and very acceptable on back level graphics 1.0, but cannot be submitted to the app store because I need graphics 2.0!
Good News
I was pleasantly surprised my app actually worked [sorry to having been so dubiousness, but after monitoring all the latest build forums I was very apprehensive that it would not even start and would require masses of code changes].
I am using storyboard extensively-every new screen is a new scene which creates a view with a widget.newTableView. Moving from screen to screen, internally destroys the scene and recreates another{holding onto a scene for later re- use has no performance benefits measurable for my app–memory use/leaks or response}. This still works-great!
Overlay scenes work , but now take about for ever…to display.
To overcome the various ‘hiccups’ on back level, I use loads of object:seReferencePoint() and extensive use of object:setFillColor() and object:setStrokeColor() so far during tests these also work as intended on this latest version.
Not so good news
The application now is very very sluggish! and many ‘bugs’/problems with table view positioning
NOTE I have done no research or intense debugging yet ,so this is just feedback and a request for any suggestion, that are obvious, from the latest build user, i.e are the following concerns fixed, or do are start hacking my code to try to get around these in-hibitors to getting my app published. In it’s current condition it would be almost unusable and would destroy it’s marketing image.
-
A new screen came up is a blink of an eye-milliseconds, on the back level. Now it can take 1.5 seconds! OUCH Serious advise needed here?
-
Tableviews come up at top left corner as designed-but any scrolling is dramatically clunky and re-positions left middle of the screen. Smooth speed scroll has gone! It would seem compatibility only works on first painting of the table, after that all reference is as Graphics 2-i.e. compatibility is not consistent through the life of the app. Removing line list:scrollToIndex( actualScrollto,450 ) helps , but not in all cases…
3.My main table view [called dashboard] which has entries larger that the screen will not scroll up and show lower entries- while other views of tables in different scenes do allow lower level rows to be scrolled up, but in clunky painting and very jumpy and unpleasing fashion [must be some differences in my code helping cause this miss-function].
-
Tapping on the ‘dashboard’ can take over 4 to 10 seconds to highlight the tapped entry, kill the scene, create the next scene, create the table view and paint the display-in back level graphics 1.0 this was all done correctly in just milli-seconds.
-
Scene overlay- This is where I first scan the contents of the Table View by scrolling to the end and add numbers in RowRender routine and then display the stats in an overlay scene{sounds messy but actually worked and looked OK and usable. Now it can take 12 seconds with a blank screen{ presumably firing rowrender events} another 3 seconds flashes the table contents scrolled up, then another 4-seconds the overlay scene is displayed. Taping the overlay takes 3 seconds to dissapear and the return to the tableview positioned at mid left, not top left as required in compatibility mode.
Run time messages
Speed varies in all tests, some times many many seconds, then later just a few. Looking at memory needs of the app which are kept at a minimum these show
Memory used 1111.22 TEXTURE Used 0.77407073974609
Memory used 1024.31 TEXTURE Used 0.71668243408203
Ther are masses of warning messages, masses and masses - can I stop these as thes undoubtably are slowing the system?
WARNING: object:setReferencePoint() was given a ‘nil’ value. The behavior is not defined.
Ok that’s enough to think on for now…
So I guess it is back to more testing and reading and hacking the code if I wish to publish a Corona Business app using widgets…
I guess one response will be move to the daily builds by buying the Basic license- Yes, a possible route but who can assure this will improve my case. I would love to submit my back0level as it is really cool and friend love its speed and functionality.
