Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1693] scrolling performance and redraw issues, table row class name scroll

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionFixed
Resolution Date2011-04-17T01:56:53.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.5.0
ComponentsiOS
Labelsdefect, ios, redraw, scroll
ReporterThomas Huelbert
AssigneeStephen Tramer
Created2011-04-15T02:59:40.000+0000
Updated2011-04-17T01:56:53.000+0000

Description

1.use this script (thanks to gero):

var max = 100;
var data = [];

for (var c=0; c<max; c++) {

var row = Ti.UI.createTableViewRow({
    className: 'feedlist',
    height: 'auto'
});

var textview = Ti.UI.createView({
    layout: 'vertical',
    height: 'auto'

});

var h1 = Ti.UI.createLabel({
    text: 'Title title title #'+c,
    height: 'auto'
});
textview.add(h1);

var cre = Ti.UI.createLabel({
    text: 'Creator creator creator#'+c,
    height: 'auto',
    color: '#ccc'
});
textview.add(cre);

row.add(textview);
data[c] = row;

}

var win = Ti.UI.createWindow();
var tableview = Ti.UI.createTableView();
tableview.setData(data);
win.add(tableview);
win.open();

2.scroll up and down, note the performance
3.look at the bolded text

results:scroll performance is poor, and after some scrolling there are redraw issues on the text.

Attachments

FileDateSize
tiissue_1693_badrender.png2011-04-15T02:59:41.000+0000167550
tiissue_1693_norender.png2011-04-15T02:59:41.000+0000126248

Comments

  1. Robby 2011-04-15

    1. At least with 1.4.0, I am noticing the same type of performance and redraw issues with scrolling of one of my tableviews, which uses multiple labels, imageviews, for each row.
  2. Jean-Etienne LaVallee 2011-04-15

    I'm seeing the same issue... specifically, the initial draw of the table doesn't render anything until I do something to trigger an event in the the tableView. At that point, either some or all of the rows will render but in many cases the log will throw out a ton of "Orphaned child found during proxy transfer!" errors and there will be duplicate data transposed or overlaid from other tableViewRows. (see attached PNGs)

    My only solution thus far has been to give each row a unique className (if I suppress className all together then it doesn't render at all). But even then it still is only rendering the rows after the table receives an initial event (click, drag, etc.).

    Is there an interim fix for this? I have a demo on friday and the app I'm working on relies largely on presenting data in custom tableViewRow layouts.

    Thanks!

  3. Jean-Etienne LaVallee 2011-04-15

    FYI, I'm currently on TiDev 1.2.1, TiSDK 1.4.0, and iOS SDK 4.0.1

  4. Jean-Etienne LaVallee 2011-04-15

    Well, for the time being I'm able to get the initial render to occur by doing this:

    this.contactListTable.scrollToTop(1, {

       animated: true,
       position:Ti.UI.iPhone.TableViewScrollPosition.TOP
       

    });

    Immediately after the initializer that builds the view is called. It's not pretty, but it'll get the job done for now.

  5. Stephen Tramer 2011-04-15

    Jean-Etienne, these issues you describe may be fixed in master/HEAD. They were known issues in 1.4.0 and the bug which described similar behavior has been closed. See bug #1250.

  6. Jean-Etienne LaVallee 2011-04-15

    Stephen, thanks for the pointer! totally missed the #1250 bug...

    Generally is it safest to work off of master/HEAD or from the latest official release?

    And how do I install from master/HEAD? Pull down that revision from github and then put it in my /Library/Application Support/Titanium/mobilesdk/osx/ directory?

    Or if there are instructions elsewhere and I'm being daft, just point me to the right URL.

    Thanks!

  7. Stephen Tramer 2011-04-15

    It is usually best to work off of the last stable release.

    You can go to http://github.com/appcelerator/titanium_mobile">http://github.com/appcelerator/titanium_mobile and download the source there. Then run scons, copy the development library from the dist directory, and unzip it in /Library/Application Support/Titanium.

  8. Jean-Etienne LaVallee 2011-04-15

    Nevermind... took me a bit, but I found the nightly build server... why isn't that published somewhere more accessible?

  9. Robby 2011-04-15

    I tried the newest nightly and didn't see this problem anymore (maybe I missed it though -- Thomas/Jean, you may want to confirm). However, I have developed a test case for a related rendering problem involving the Navbar: Ticket https://appcelerator.lighthouseapp.com/projects/32238-titanium-mobile/tickets/1726-hidenavbarshownavbar-on-tableview-searchbar-focusblur-whites-out-first-page-of-results"> 1726

  10. Jean-Etienne LaVallee 2011-04-15

    @Robby: Using the nightly build from the Sept 1, I'm not longer seeing this issue and was able to remove the 1pixel scroll hack I had to use to get the table to initially display.

    @Steve: Thanks, yeah, I figured out the install process... I'm going to keep working off of the Sept 1 nightly since it does fix a number of issues I was experiencing from 1.4.0

  11. Stephen Tramer 2011-04-15

    Revisiting this issue because of recent tableview performance problems. Looks like it's still serious.

  12. Jeff Haynie 2011-04-15

    (from [e12366086233dddaf83cd53518a489ce0788d29f]) [#1693 state:fixed-in-qa] Only tell the parent that the child is resizing if it actually, you know, is resizing. https://github.com/appcelerator/titanium_mobile/commit/e12366086233dddaf83cd53518a489ce0788d29f"> https://github.com/appcelerator/titanium_mobile/commit/e12366086233...

  13. Thomas Huelbert 2011-04-15

    Back to Stephen - 1.5.0.3ee6a97 Looks really good on 4th gen ipod touches running 4-4.2.1, but on 3rg gen touch(4.0.1) and an iphone 3g (3.1.3) there are redraw problems where the list draws in on the bottom of the screen while scrolling, first time scroll only (smooths out on a second scroll). It's much, much better than it was, but can it be improved on the slower hardware? if not, will close (hesitant to even bounce it back as its so dramatically improved...)

  14. Stephen Tramer 2011-04-15

    This is just natural draw times (drawing auto/vertical layouts takes a long time because of all of the dimension calculation involved on our end). We're getting into the realm of view system draw improvements in general at this point.

    Going to switch back to fixed-in-qa - feel free to create a feature/enhancement request for faster view draw times.

  15. Thomas Huelbert 2011-04-15

    Thanks for the info Stephen, closing

JSON Source