Cell-backed table view doesn't update its preparedContentRect aggressively enough

Originator:jalkut
Number:rdar://26320335 Date Originated:17-May-2016 08:34 AM
Status:Open Resolved:
Product:OS X Product Version:10.11.4 (15E65)
Classification:Serious Bug Reproducible:Always
 
Summary:
In some cell-backed table views, whose scroll view is configured to allow responsive scrolling, dynamic table content may not be redrawn as expected when the view is resized.

I discovered this behavior in NSTableView while debugging a behavior in my long-shipping app, FlexTime. Because of time constraints, I abandoned pursuit of a concise, reproducable test case, but I thought I'd report the bug so somebody on the AppKit team can hopefully review whether the behavior I'm seeing is indeed an Appkit bug, and whether it has wider implications than just the cell-backed table view issue I'm seeing.

Steps to Reproduce:
1. Download FlexTime: https://www.red-sweater.com/flextime/FlexTime1.3.zip

2. Open the app and create a new, default document.

3. Press the Play button to start the default, boilerplate document "running." Witness the animated pie chart in the last column of the main window's table view.

4. Resize the window by grabbing the lower right corner and expanding to make the window much larger.

Expected Results:
The animating pie chart should continue drawing.

Actual Results:
The animating pie chart ceases to draw. It turns out this is because the preparedContentRect for the view has gone stale and reflects the old rectangle. Consequently when the view is internally asked to determine visible columns needing redrawing, it disregards the column containing the constantly-updating pie-chart progres indicator. 

If you set a breakpoint on prepareContentInRect: you will see that the preparedContentRect is often only updated at the beginning of a live resize and not at the end. I suspect something in NSTableView's handling of the live resize is overly-certain that the resize does not affect the visible content of the table view, particularly when growing the table to larger than its previously "prepared" size.

I've worked around the issue in my app by overriding -[NSTableView preparedContentRect] to return -[NSTableView visibleRect].


Version:
10.11.4 (15E65) 

Notes:


Configuration:
MacBook Pro 2014 edition 15"

Attachments:

Comments

Note also that you can 'jog' the redrawing back to normal by doing any number of things that force NSTableView to reconsider its preparedContentRect. For example, two-finger swiping the view to scroll, clicking the column header and dragging as if to reoder, or initiating another window resize. Note however that if you resize the window to yet a larger size, you may inflict the bug on the view again.

By jalkut at May 17, 2016, 12:40 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!