Widget 2.0 Tableview Performance

Thanks for the update Danny!

Thanks Danny.  congrats on the release yesterday - big step forward.  

Danny,

Just noting that i do not see this solved in 1080.  Don’t know if you have had time to complete the work you mentioned or not.  Updating the observed status of this issue.

Cheers,

m

On Build 1093 i still see all the rows getting rendered even if off screen.  This continues to be a substantial performance issue.  Any update on getting round to this item?

Thanks

Hi mslack,

1093 should have fixed the behaviour. If you still have performance issues, please fill in a bug report, together with a testbed so that we can see the configuration you are running. I’ll then look into it.

Thanks!

Alex.

mslack, are you seeing any performance improvements? I’m debating whether or not I should convert my app from the old widgets to the new ones

I’m going to go with NO … here is the print out for a table with 60 rows in it … only 8.5 of them are on screen at any one time.   As soon as the table is rendered it renders all of the rows:

Rather hateful of this issue as i cannot release this app till corona fixes this issue!!!

The real problem is that i have been asked to fill create all these test cases for bugs in these 2.0 widgets that are not subtle issues.  They should be part of their standard testing in most cases.  Who has time to do all that extra work associated with creating these test cases for their software … sigh … sorry … was i ranting … :slight_smile:

ps … running on Build: 2013.1093

2013-04-26 08:23:46.866 Corona Simulator[77354:707] Rendering row: 1 2013-04-26 08:23:46.871 Corona Simulator[77354:707] Rendering row: 2 2013-04-26 08:23:46.875 Corona Simulator[77354:707] Rendering row: 3 2013-04-26 08:23:46.879 Corona Simulator[77354:707] Rendering row: 4 2013-04-26 08:23:46.884 Corona Simulator[77354:707] Rendering row: 5 2013-04-26 08:23:46.889 Corona Simulator[77354:707] Rendering row: 6 2013-04-26 08:23:46.895 Corona Simulator[77354:707] Rendering row: 7 2013-04-26 08:23:46.901 Corona Simulator[77354:707] Rendering row: 8 2013-04-26 08:23:46.907 Corona Simulator[77354:707] Rendering row: 9 2013-04-26 08:23:46.912 Corona Simulator[77354:707] Rendering row: 10 2013-04-26 08:23:46.918 Corona Simulator[77354:707] Rendering row: 11 2013-04-26 08:23:46.923 Corona Simulator[77354:707] Rendering row: 12 2013-04-26 08:23:46.929 Corona Simulator[77354:707] Rendering row: 13 2013-04-26 08:23:46.937 Corona Simulator[77354:707] Rendering row: 14 2013-04-26 08:23:46.944 Corona Simulator[77354:707] Rendering row: 15 2013-04-26 08:23:46.949 Corona Simulator[77354:707] Rendering row: 16 2013-04-26 08:23:46.955 Corona Simulator[77354:707] Rendering row: 17 2013-04-26 08:23:46.960 Corona Simulator[77354:707] Rendering row: 18 2013-04-26 08:23:46.966 Corona Simulator[77354:707] Rendering row: 19 2013-04-26 08:23:46.972 Corona Simulator[77354:707] Rendering row: 20 2013-04-26 08:23:46.978 Corona Simulator[77354:707] Rendering row: 21 2013-04-26 08:23:46.983 Corona Simulator[77354:707] Rendering row: 22 2013-04-26 08:23:46.990 Corona Simulator[77354:707] Rendering row: 23 2013-04-26 08:23:46.995 Corona Simulator[77354:707] Rendering row: 24 2013-04-26 08:23:47.001 Corona Simulator[77354:707] Rendering row: 25 2013-04-26 08:23:47.006 Corona Simulator[77354:707] Rendering row: 26 2013-04-26 08:23:47.012 Corona Simulator[77354:707] Rendering row: 27 2013-04-26 08:23:47.018 Corona Simulator[77354:707] Rendering row: 28 2013-04-26 08:23:47.023 Corona Simulator[77354:707] Rendering row: 29 2013-04-26 08:23:47.029 Corona Simulator[77354:707] Rendering row: 30 2013-04-26 08:23:47.035 Corona Simulator[77354:707] Rendering row: 31 2013-04-26 08:23:47.041 Corona Simulator[77354:707] Rendering row: 32 2013-04-26 08:23:47.046 Corona Simulator[77354:707] Rendering row: 33 2013-04-26 08:23:47.053 Corona Simulator[77354:707] Rendering row: 34 2013-04-26 08:23:47.058 Corona Simulator[77354:707] Rendering row: 35 2013-04-26 08:23:47.064 Corona Simulator[77354:707] Rendering row: 36 2013-04-26 08:23:47.070 Corona Simulator[77354:707] Rendering row: 37 2013-04-26 08:23:47.076 Corona Simulator[77354:707] Rendering row: 38 2013-04-26 08:23:47.081 Corona Simulator[77354:707] Rendering row: 39 2013-04-26 08:23:47.087 Corona Simulator[77354:707] Rendering row: 40 2013-04-26 08:23:47.093 Corona Simulator[77354:707] Rendering row: 41 2013-04-26 08:23:47.099 Corona Simulator[77354:707] Rendering row: 42 2013-04-26 08:23:47.105 Corona Simulator[77354:707] Rendering row: 43 2013-04-26 08:23:47.111 Corona Simulator[77354:707] Rendering row: 44 2013-04-26 08:23:47.117 Corona Simulator[77354:707] Rendering row: 45 2013-04-26 08:23:47.123 Corona Simulator[77354:707] Rendering row: 46 2013-04-26 08:23:47.130 Corona Simulator[77354:707] Rendering row: 47 2013-04-26 08:23:47.135 Corona Simulator[77354:707] Rendering row: 48 2013-04-26 08:23:47.142 Corona Simulator[77354:707] Rendering row: 49 2013-04-26 08:23:47.147 Corona Simulator[77354:707] Rendering row: 50 2013-04-26 08:23:47.153 Corona Simulator[77354:707] Rendering row: 51 2013-04-26 08:23:47.160 Corona Simulator[77354:707] Rendering row: 52 2013-04-26 08:23:47.165 Corona Simulator[77354:707] Rendering row: 53 2013-04-26 08:23:47.171 Corona Simulator[77354:707] Rendering row: 54 2013-04-26 08:23:47.177 Corona Simulator[77354:707] Rendering row: 55 2013-04-26 08:23:47.184 Corona Simulator[77354:707] Rendering row: 56 2013-04-26 08:23:47.189 Corona Simulator[77354:707] Rendering row: 57 2013-04-26 08:23:47.196 Corona Simulator[77354:707] Rendering row: 58 2013-04-26 08:23:47.202 Corona Simulator[77354:707] Rendering row: 59 2013-04-26 08:23:47.208 Corona Simulator[77354:707] Rendering row: 60

Hey.

All the row’s will get rendered once initially. After they are rendered the off screen ones are culled.

Mslack,

It’s not like we can’t make our own test cases. We ask you guys to create tests so that we can see the exact environment you use, how the code looks like, etc. In a lot of cases, we have people sending in bugs that are actually mistakes in their own code.

So don’t get it wrong, but it’s important for us to have the testcase from you.

Alex

Yea

Sure but that is the problem.  If it is not on screen why is it rendered at all.  Im my case, i have to run a fairly complex DB query to render a row so it gets slow quickly.  Certainly, there is no need to render the rows that are off screen.  I am fairly certain that i remember that widget 1.0 did not render things till they were on screen.

I agree, they shouldn’t be. I will get this addressed asap. I was hospitalised for the last few weeks hence my lack of attendance in these discussions lately. 

I understand.  Just have been asked to create a fair number of these testcases lately and been a bit frustrated with this widget 2.0 migration … going better now so i apologize for the rant.

On the performance issue here what is it that you need?  The performance is slow because all the rows are rendered upon creation.  Cannot imagine why that is necessary … each row gives you its height.  The test case to show that all rows are rendered is trivial … create a table view with more than enough rows to fill it.  Can you give me guidance on what the bug report should be?

Very sorry to hear that.  Hopefully you are on the mend and it is nothing too serious. … all the best.

Wow, quick replies :slight_smile: Guess I’ll hold off with the migration a little while longer.

Edit: Would just like to point out that the fact that the tableView renders ALL rows initially is a major flaw imo - since you can quickly run out of memory as well.

^ I’ll be holding off as well. This performance issue is a bad one. Everything else has been doing better, but this is a biggy for me.

I’m seeing the same thing as mslack.

TableView 1.0 would do “lazy loading”, and only call onRowRender when rows were actually being rendered (as opposed to 2.0, which calls onRowRender whether or not the row is actually being rendered). That tableview 1.0 lazy loading was good stuff… VERY good stuff.

TableView 2.0 however, tries to load everything at instantiation – which can cause other problems not easily worked around…

Some of my tables includes a photo to be downloaded fro a server for every row, and if the list has 100 rows in it, the system chokes trying to send out request for 100 graphics all in an instant. The same holds true when the serve tries to send back request for 100 graphics at once.

Perhaps adding an onInit() handler for rows, which is called on row creation would help solve coronaLabs issues (and only calling onRowRender when the row is actually rendered - as the functions name implies)?

If the lazy loading doesn’t come back soon, I’m going to have to rewrite my tableView handlers to manually do the lazy loading… And it would be difficult to emulate the precision and grace that tableView 1.0 managed.

Yes this is how it should function and will be added back asap. It does do this once all rows are rendered, it then loads and displays them based on whether they are on or off screen. The issue of them all being rendered initially does need fixing however.

Just a side note, please remember that widget 1.0 had tons of issues (showstoppers and more) that people tend to forget nowadays. We didn’t re-write the widget library for nothing :slight_smile:

That’s great news Danny! That lazy loading stuff saves an incredible amount of developer time in managing resources (the internet connection in my app case - besides potential issues regarding texture memory trying to load all those images at once).

Agreed that 1.0 had issues – I had to undo some of my “issue workaround” code when migrating to 2.0, but it seems to be working pretty well now (other than lazy loading).

With the sophisticated strategy for lazy loading adopted into tableView 2.0, you’ll have a world class list widget on your hands…

I can’t say enough about how elegant / graceful that particular lazy load strategy is… It’s an algorithmic / code design work of art :slight_smile:

On Build 1093 i still see all the rows getting rendered even if off screen.  This continues to be a substantial performance issue.  Any update on getting round to this item?

Thanks

Hi mslack,

1093 should have fixed the behaviour. If you still have performance issues, please fill in a bug report, together with a testbed so that we can see the configuration you are running. I’ll then look into it.

Thanks!

Alex.