1.use this script (thanks to gero):
\nvar max = 100;
\nvar data = [];
for (var c=0; c<max; c++) {
\nvar row = Ti.UI.createTableViewRow({\n className: 'feedlist',\n height: 'auto'\n});\n\nvar textview = Ti.UI.createView({\n layout: 'vertical',\n height: 'auto'\n\n});\n\nvar h1 = Ti.UI.createLabel({\n text: 'Title title title #'+c,\n height: 'auto'\n});\ntextview.add(h1);\n\nvar cre = Ti.UI.createLabel({\n text: 'Creator creator creator#'+c,\n height: 'auto',\n color: '#ccc'\n});\ntextview.add(cre);\n\nrow.add(textview);\ndata[c] = row;\n\n}
\nvar win = Ti.UI.createWindow();
\nvar tableview = Ti.UI.createTableView();
\ntableview.setData(data);
\nwin.add(tableview);
\nwin.open();
2.scroll up and down, note the performance
\n3.look at the bolded text
results:scroll performance is poor, and after some scrolling\nthere are redraw issues on the text.
I'm seeing the same issue... specifically, the initial draw of\nthe table doesn't render anything until I do\nsomething to trigger an event in the the tableView. At that point,\neither some or all of the rows will render but in many cases the\nlog will throw out a ton of \"Orphaned child found during proxy\ntransfer!\" errors and there will be duplicate data transposed or\noverlaid from other tableViewRows. (see attached PNGs)
\nMy only solution thus far has been to give each row a unique\nclassName (if I suppress className all together then it doesn't\nrender at all). But even then it still is only rendering the rows\nafter the table receives an initial event (click, drag, etc.).
\nIs there an interim fix for this? I have a demo on friday and\nthe app I'm working on relies largely on presenting data in custom\ntableViewRow layouts.
\nThanks!
FYI, I'm currently on TiDev 1.2.1, TiSDK 1.4.0, and iOS SDK\n4.0.1
Well, for the time being I'm able to get the initial render to\noccur by doing this:
\nthis.contactListTable.scrollToTop(1, {
\nanimated: true,\nposition:Ti.UI.iPhone.TableViewScrollPosition.TOP\n\n});
\nImmediately after the initializer that builds the view is\ncalled. It's not pretty, but it'll get the job done for now.
Jean-Etienne, these issues you describe may be fixed in\nmaster/HEAD. They were known issues in 1.4.0 and the bug which\ndescribed similar behavior has been closed. See bug #1250.
Stephen, thanks for the pointer! totally missed the #1250\nbug...
\nGenerally is it safest to work off of master/HEAD or from the\nlatest official release?
\nAnd how do I install from master/HEAD? Pull down that revision\nfrom github and then put it in my /Library/Application\nSupport/Titanium/mobilesdk/osx/ directory?
\nOr if there are instructions elsewhere and I'm being daft, just\npoint me to the right URL.
\nThanks!
It is usually best to work off of the last stable release.
\nYou can go to http://github.com/appcelerator/titanium_mobile\nand download the source there. Then run scons, copy the development\nlibrary from the dist directory, and unzip it in\n/Library/Application Support/Titanium.
Nevermind... took me a bit, but I found the nightly build\nserver... why isn't that published somewhere more accessible?
I tried the newest nightly and didn't see this problem anymore\n(maybe I missed it though -- Thomas/Jean, you may want to confirm).\nHowever, I have developed a test case for a related rendering\nproblem involving the Navbar: Ticket \n1726
@Robby: Using the nightly build from the Sept 1, I'm not longer\nseeing this issue and was able to remove the 1pixel scroll hack I\nhad to use to get the table to initially display.
\n@Steve: Thanks, yeah, I figured out the install process... I'm\ngoing to keep working off of the Sept 1 nightly since it does fix a\nnumber of issues I was experiencing from 1.4.0
Revisiting this issue because of recent tableview performance\nproblems. Looks like it's still serious.
(from [e12366086233dddaf83cd53518a489ce0788d29f])\n[#1693 state:fixed-in-qa] Only tell the parent\nthat the child is resizing if it actually, you know, is resizing.\n\nhttps://github.com/appcelerator/titanium_mobile/commit/e12366086233...
Back to Stephen - 1.5.0.3ee6a97 Looks really good on 4th gen\nipod touches running 4-4.2.1, but on 3rg gen touch(4.0.1) and an\niphone 3g (3.1.3) there are redraw problems where the list draws in\non the bottom of the screen while scrolling, first time scroll only\n(smooths out on a second scroll). It's much, much better than it\nwas, but can it be improved on the slower hardware? if not, will\nclose (hesitant to even bounce it back as its so dramatically\nimproved...)
This is just natural draw times (drawing auto/vertical layouts\ntakes a long time because of all of the dimension calculation\ninvolved on our end). We're getting into the realm of view system\ndraw improvements in general at this point.
\nGoing to switch back to fixed-in-qa - feel free to create a\nfeature/enhancement request for faster view draw times.
Thanks for the info Stephen, closing