Tableview Build event required - Called immediately after 'table' has 'painted' onscreen:

Solar2D Advanced Graphics
#1

Moving between scenes we have the  ‘enterScene’ event that I use to turn off  the spinner ‘spinner:stop()’ after gotoscene did a spinner:start().

This is working as expected. Spinner can be seen when a scene is slow displaying .

However, when I refresh/rebuild a large tableview within a scene and spinner:start() before building the TableView and then do spinner:stop() in onRowRender( event ) on last row, I never see the spinner. It completes too fast or is hidden behind scene objects/table.

I have tried to debug this and one of two things, maybe both,  seems to be a problem.

There is no event  that tells us when the table list has completed  being ‘painted’ on the screen. So

  1. Debugging shows that the spinner:stop() is run too soon to be seen before table completely appears onscreen. It  seems that the row render is done in the background, then ‘painted’ after. Is this the case? If I do a WithDelay  then spinner:Stop() the spinner is seen, sometimes. Is there any planned/suggest event that I should/could use?

  2. Sometimes I cannot see the spinner, either because it is too dull or is not being shown on top [position left and top are screen centres]. I have tried spinner:toFront() but that had no effect. Is there a way to give the spinner a higher contract/colour  or how to check it is being visible even if it cannot be seen [my glasses are new :}]

Thanks

#2

Your computer and handheld devices are very fast.  Its very possible to insert a bunch of rows into a table, have it render the 10 rows or show that it shows all within one frame cycle.   Also if you are waiting on say row 40 to render, it won’t until it’s on screen.

Rob

#3

Thanks Rob, understand…

When trialing on an iPhone 4s, [faster devices less noticable but still a hint of following problem] I touch a visable row on one table[call it A]  that creates a new table,  and there is a delay of at least 500 miliseconds on the original viewed table touch [highlighted] before anything changes on screen, or more, and it appears to the user that the app has locked , a while.

There are about 52 rows  on the new table [call it B] that we are waiting for.  With ‘just’ 52  rows in table B  the tableview list does not fill the screen in portrait[very narrow height rows]. In landscape only about 18 rows  are  visible [all very narrow to show a pattern like a chess board, 50 across]. Here in landscape only partly filled so last row never seen until user scrolls up.

When the original table A is touched,  spinner:start() is called, then a change of storyboard scene occurs. Table B is then built in the new scene in the ‘createscene’ event.  In the ‘Rowrender’ event each row has to examine data and highlight sections of the ‘chess board’ effect, looking at prior and expected next rows to map out the desired pattern, which takes some ‘complex’ processing time on each row render. Hence the need for spinner to appear while building the TableB, until the table is viewable on the screen.  [hence the request for an event that fires when the table has reached the limit and ‘painted’ (70 -end of, or 18 rows -only veiwable)-each case rows rendered has completed and now displaying on screen- however now due to possible processing bound multitalking lockouts (see below) another event may not solve this, becuase like you I had assumed things were happening too fast to see the spinner…].

In the code I stop the spinner in two places.

  1. Stopped in the enterScene event when transferred from another scene:

[most of the time no spinner seen. Spinner  was expected all the time on slower devices while table is built. The app appears very hesitant at touch row table A , the spinner should show because before gotoscene we do spinner:start(). In other scenes that do not do much processing, per table A row the spinner appears momentarily. So, in my view,  it is something to do with multi-tasking.  It would seem that a  row render process can ‘lock out’ other activities if heavily  processor bound. If this is the case]

  1. Or Stopped in the row render event, only  when the table B is rebuilt within the same scene;

[Here we do spinner:start(), deleteRows and then rebuild the tableview list. In this situation we never see the spinner, I think due to so much processing  in the  row render event, within the same scene - no gotoscene here.]

However, after all that I still have some further thoughts on this following piont.

Note However : In portrait I physically see the last row appear in the row render event as it is on the screen. In landscape the last row does can not be physically seen  [ so in theory but not desired,   the spinner should be still shown spinning in landscape as the last row is not seen; this ‘thought’ highlighted the problem initially in testing. Here the spinner is seen still running!!

This means it  is  not  ‘a too quick to be seen’ issue,  but  is a multiprocess lockout issue-because nothing is seen when table A does spinner:stop() before scene changes.Here in landscape the spinner is not seen until the actual tableview has finished appearing even in landscape and only 18 rows have been ‘painted’

I hope this helps understand the raise forum subject, I have tried mainy other ways to get the spinner appearing in the process bound situation but without success. In other situations the spinner spins happily and is working fine e.g. while downloading asychrounously, other different scene to scene change and so on.…

At one point I thought the spinner might be hidden, but if I do a spinner:stop()  withdelay, of a few seconds then the spinner can be seen running after the table is completed in portrait or landscape…

Thanks for the feedback.

Alec

#4

I have just 'hacked tab1 from  CoronaSDK/SampleCode/Interface/WidgetDemo/tab1.lua to show lockout out screen until table painted

on screen that I am experiencing…

Could you remind me how to upload source for your reference…?

Thanks

Alec

PS Where did the Enthusiastic over my hat originate? but thanks…

update!

{I have submitted this as a bug now}

PPS :The issue of the spinner being dull on garish screen has not been addressed yet. Any suggestions?

#5

Please post the bug Case # here as a reference.  I can then go download your test case.

Rob

#6

This is the case number

(Case 40089) Screen lock out with heavy TableView build processing

You will need to place tab1 with the uploaded module in the sample code…

Thanks

Alec

#7

I have not had feedback on the status except the above case number. I would have  liked to have had a solution to this  by next month as the app gets closer to publishing…

At the moment I still see a hang while the app processes tableview creation.

I know this is possibly low in the scheme of all you have in hand.

Thanks in anticipation.

#8

I just looked at the bug submission and it’s missing a project to reproduce the problem.  You attached a .lua file, but you did not include the config.lua and build.settings or the main.lua.  I tried to grab the code and see myself, but it immediatly errors because there are things in your main.lua that the scene is dependent on.  Please produce a .zip file with all the required assets.   In other words, QA will unzip the folder, open the folder in the simulator and want to see what you’re reporting.  They cannot do that with what you sent and we can’t afford the time to try and reconstruct the missing pieces.

I’m going to respond to the ticket so you will get a new email that you should be able to attach the .zip file too.

Also, can you explain the use case for putting 50 display objects in one row?  Trying to get that many rows on the screen at once?  The screen shot doesn’t look like something you would use a tableView for.

Rob

Rob

#9

Thanks I will look at the email.

Sorry that the case was missing the project. I just sent a TAB.lua  from the corona samples and hope it could be merged. I will recreate and send as requested.

Example of [possible] 50 objects in a row…

This is   copyright ColourMyApps Ltd., but if you take a game which can draw 5 from 50 numbers.

So to draw a graphical history map, one row for each game to see a pattern over time , to see if there is a bias, the easiest way I could see was to map the results into each tableview row, for each game.

So if a game result is 5,18,35,47,50 these are the positions across the row that will have the ‘square’ highlighted. So although only 5 per row each row is ‘marked’ in special ways to show and highlight any close numbers or repeats or directional 'drift’s  over the last few games [bias]. So for every row, the prior rows are looked at to mark ‘trends’ and highlight ‘squares’ as to next likley ‘game’. some will be dark, while others will be lighter. There are games in real life that having 5 from 50, or similar results that will be better understood. What I sent was just a random mix for testing processor bound lock-out of the spinner.

I am looking at speeding this up by just hitting the actual square,from  internal table lookups, instead of scanning/plotting all 50 positions.

Even so there is still some processing before the objects are drawn and this does cause the spinner to be not shown until tableview is built.

Thanks

Alec

#10

I’m not sure how much of a bug this is actually.   Your code snippet has a couple of things and then there is how Corona renders frames. 

You’re spinner is logically behind the tableView.  You’re not going to see the spinner because it’s behind a solid object.  I changed the order to create the tableView first and now I can see the spinner… sort of.

Corona SDK renders things on a frame cycles.  Basically when you do:

for i = 1, 3000

   – do some work

end

All of that work will render on the next frame update.  If you do more work in a frame cycle than the frame rate can support, you get a delayed update.  For the most part, Corona SDK is a single threaded process.  Somethings like audio will run on a different thread, but a given block of Lua code has to complete before the update happens.  If you wrap your for loop into a function called doWork() or some such then call that in a timer.performWithDelay(20, doWork) you will see the spinner, but it doesn’t spin once doWork() starts working.  By the time your 3000 rows are created you have already cancelled the spinner before the next frame update happens.

This might be a good use for a CoRoutine, Lua’s equiv. to threads.  See this tutorial:

https://coronalabs.com/blog/2015/02/10/tutorial-using-coroutines-in-corona/

Rob

#11

Understood. I forgot the runspinner:toFront() in my test run. So also now, sortoff see it, at the end.

Do you have any thoughts on being able to highlight the spinner more for the dark or gawdy scene[if/when  I get it working ok]?

About a year ago I came across this problem and tried to write a ‘dispatcher’ via timer.performWithDelay to build the table, but dismissed it then due to getting too complex from the then limited knowledge of Corona. I will go back and look  and compare using coroutines [or maybe re-write the offending routines]. Thanks for the link.

Thanks

Alec

#12

https://coronalabs.com/blog/2015/02/10/tutorial-using-coroutines-in-corona/

http://www.jucs.org/jucs_10_7/coroutines_in_lua/de_Moura_A_L.html#conw63

reminiscing…

Very very interesting. At around that 1965/6 I was working on multi-tasking language called PL/1

http://en.wikipedia.org/wiki/PL/I

Later working on CNC machines and CAD.

http://en.wikipedia.org/wiki/History_of_numerical_control

Writing  dispatchers at machine assembler code level called process control [CNC is  now moved onto robotics I guess] that is exactly as mentioned under Coroutines.

I have never heard it called that before [IBMers always had their own language] hence not noticing the referenced articles.

The technique could be very useful, I suspect in mutiple image moving games…

Thanks for that,

Alec

An after thought…

How about using this for co routine style scenes in composer and/or storyboards to allow muliple scenes r_unning…displaying in different screen sections/boxes_

#13

For what it’s worth, my first official programming class was using PL/C and PL/I back in 1980.  Though by the time I got there I had taught myself BASIC and DEC TOPS-10 assembler.  Dabbled in SAIL, ALGOL then it was IBM 370 assembler and then on to Pascal and FOTRAN.  Or something like that.  Then I learned C and basically purged every other language out of my head.

Rob

#14

I thought I could see hints of that thinking here in Corona.

Without boaring the readers, too much,  I went onto windows and Visual Basic [VBA} lecturing and that kept me busy for 10 years. So now just trying all that out here in Corona…

nuf said!

#15

Your computer and handheld devices are very fast.  Its very possible to insert a bunch of rows into a table, have it render the 10 rows or show that it shows all within one frame cycle.   Also if you are waiting on say row 40 to render, it won’t until it’s on screen.

Rob

#16

Thanks Rob, understand…

When trialing on an iPhone 4s, [faster devices less noticable but still a hint of following problem] I touch a visable row on one table[call it A]  that creates a new table,  and there is a delay of at least 500 miliseconds on the original viewed table touch [highlighted] before anything changes on screen, or more, and it appears to the user that the app has locked , a while.

There are about 52 rows  on the new table [call it B] that we are waiting for.  With ‘just’ 52  rows in table B  the tableview list does not fill the screen in portrait[very narrow height rows]. In landscape only about 18 rows  are  visible [all very narrow to show a pattern like a chess board, 50 across]. Here in landscape only partly filled so last row never seen until user scrolls up.

When the original table A is touched,  spinner:start() is called, then a change of storyboard scene occurs. Table B is then built in the new scene in the ‘createscene’ event.  In the ‘Rowrender’ event each row has to examine data and highlight sections of the ‘chess board’ effect, looking at prior and expected next rows to map out the desired pattern, which takes some ‘complex’ processing time on each row render. Hence the need for spinner to appear while building the TableB, until the table is viewable on the screen.  [hence the request for an event that fires when the table has reached the limit and ‘painted’ (70 -end of, or 18 rows -only veiwable)-each case rows rendered has completed and now displaying on screen- however now due to possible processing bound multitalking lockouts (see below) another event may not solve this, becuase like you I had assumed things were happening too fast to see the spinner…].

In the code I stop the spinner in two places.

  1. Stopped in the enterScene event when transferred from another scene:

[most of the time no spinner seen. Spinner  was expected all the time on slower devices while table is built. The app appears very hesitant at touch row table A , the spinner should show because before gotoscene we do spinner:start(). In other scenes that do not do much processing, per table A row the spinner appears momentarily. So, in my view,  it is something to do with multi-tasking.  It would seem that a  row render process can ‘lock out’ other activities if heavily  processor bound. If this is the case]

  1. Or Stopped in the row render event, only  when the table B is rebuilt within the same scene;

[Here we do spinner:start(), deleteRows and then rebuild the tableview list. In this situation we never see the spinner, I think due to so much processing  in the  row render event, within the same scene - no gotoscene here.]

However, after all that I still have some further thoughts on this following piont.

Note However : In portrait I physically see the last row appear in the row render event as it is on the screen. In landscape the last row does can not be physically seen  [ so in theory but not desired,   the spinner should be still shown spinning in landscape as the last row is not seen; this ‘thought’ highlighted the problem initially in testing. Here the spinner is seen still running!!

This means it  is  not  ‘a too quick to be seen’ issue,  but  is a multiprocess lockout issue-because nothing is seen when table A does spinner:stop() before scene changes.Here in landscape the spinner is not seen until the actual tableview has finished appearing even in landscape and only 18 rows have been ‘painted’

I hope this helps understand the raise forum subject, I have tried mainy other ways to get the spinner appearing in the process bound situation but without success. In other situations the spinner spins happily and is working fine e.g. while downloading asychrounously, other different scene to scene change and so on.…

At one point I thought the spinner might be hidden, but if I do a spinner:stop()  withdelay, of a few seconds then the spinner can be seen running after the table is completed in portrait or landscape…

Thanks for the feedback.

Alec

#17

I have just 'hacked tab1 from  CoronaSDK/SampleCode/Interface/WidgetDemo/tab1.lua to show lockout out screen until table painted

on screen that I am experiencing…

Could you remind me how to upload source for your reference…?

Thanks

Alec

PS Where did the Enthusiastic over my hat originate? but thanks…

update!

{I have submitted this as a bug now}

PPS :The issue of the spinner being dull on garish screen has not been addressed yet. Any suggestions?

#18

Please post the bug Case # here as a reference.  I can then go download your test case.

Rob

#19

This is the case number

(Case 40089) Screen lock out with heavy TableView build processing

You will need to place tab1 with the uploaded module in the sample code…

Thanks

Alec

#20

I have not had feedback on the status except the above case number. I would have  liked to have had a solution to this  by next month as the app gets closer to publishing…

At the moment I still see a hang while the app processes tableview creation.

I know this is possibly low in the scheme of all you have in hand.

Thanks in anticipation.