[API Review] RT-24916 - TableView.scrollTo(TableColumn)

[Jonathan Giles]

On 5/02/2013 7:57 p.m., John Hendrikx wrote:
> On 4/02/2013 21:02, Jonathan Giles wrote:
>> This is a fair comment: scrollTo has been designed with a 
>> 'fire-and-forget' approach in mind, but I would be loath to add a 
>> means of requesting a self-correcting scrollTo function. Wouldn't a 
>> suitable workaround be to call scrollTo after the image loading has 
>> completed in all cells?
> The problem is that image loading occurs in the background, and it is 
> not really predictable when all of them are completed.  In my example 
> application, these images are loaded from a database (when cached) or 
> from the internet when not.  It may take 10 seconds before one has 
> been loaded if it wasn't cached.  Waiting that long before I restore 
> the position of the view for the user is not acceptable.  Also, 
> calling scrollTo may trigger more image loading (as new cells come 
> into view), so I'd have to call it in a loop until no more images are 
> getting loaded...

I'm confused by this statement (which isn't to say it is wrong, just 
that I don't see the distinction). Isn't the end result exactly the same 
whether you (externally) watch the progress of each of your 
image-loading cells and call scrollTo(index) as each cell completes the 
loading of the picture versus having code in the virtualisation system 
to react (internally) as the height of a cell changes (which means 
having to pay a not-inconsiderable overhead to watch the height of all 
visible cells in all cases, even when the user has no need for this 
overhead). Am I missing some nuance of your proposal that works around this?

I should note that there is a very fine balancing act that needs to 
happen in this code between performance and reliability (i.e. pixel 
perfect scrollTo behavior). It used to be the case that scrollTo would 
measure the height of every cell down to the specified index, but this 
was deemed too slow and replaced with a more performant but less 
reliable algorithm. Striking the right balance is tough.

Finally, I am operating far in excess of normal operational capacity, 
and can not imagine I will have any bandwidth to look at this, 
realistically, this year. If someone finds that the itch is unbearable, 
by all means scratch it and send me through the patch file :-). I have 
found working with external contributors has been very beneficial, so I 
am more than happy to work with more contributors in areas such as this. 
I do not mean to dismiss this discussion, I just want to be clear with 
expectations.

-- Jonathan