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

[John Hendrikx]

On 05/02/2013 08:23, Jonathan Giles wrote:
> 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 donot think it would be.  All I can do to control the position of the 
View is use scrollTo.  This function only makes the cell visible (afaik) 
and does not necessarily center it.  In other words, if some cells that 
are growing are pushing my target cell down, scrollTo won't do anything 
until the target cell actually gets pushed out of the viewport.  Once it 
gets pushed out of the viewport, then suddenly a call to scrollTo would 
center my target cell again causing a jump.  Since the loading of images 
can take tens of seconds, the shifting of the target cell and occasional 
jumps back to center could occur quite a few times.

With an internal implementation the target cell could be kept completely 
stationary regardless of how cells above or below are changing.

For a simple scrollTo() implementation to work, I'd also have to track 
every other possible interaction with the View control (scrollbar being 
dragged, cursor keys used) to know whether or not I'm still allowed to 
call scrollTo to adjust the position or that I should be respecting the 
users positioning.

With regards to overhead (but I may be completely wrong about this), I 
think you already get notified automatically when a cell changes height 
(for managed cells, when LayoutBounds changes it triggers a layout 
request up to the current layout root).  I know the cells used by 
VirtualFlow are managed as I saw this in your code.

> 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.
That is good news, I believe I filed a Jira issue with regards to 
scrollTo calculating the height of all the cells upto the specified 
index (it would trigger a lot of background loading for cells that 
weren't ever visible).  I'm not expecting pixel perfect behavior, and I 
realize that without the height of every cell known you cannot make 
perfect calculations for for example the scrollbar size and position.  
This seems hard to avoid though as calculating the height of every cell 
when there are potentially tens of thousands seems contrary to the whole 
idea of using cells in the first place (ie. performance).

Anyway, I fully realize this is not a simple problem or just a small bug 
fix.  That is why I'm trying to create my own Skin as I donot expect 
this to be fixed on short notice, or even at all due to possible 
differences in viewpoint as to how the controls should work.

But the way I'm thinking of solving this (in my own Skin) is to pay less 
attention to the cell heights, and more to the amount of cells available 
and which one should be visible.  Basically, I want to introduce the 
concept of a target cell (which usually will be the focused one).  The 
layout code will make every effort to keep this target cell stable at 
the position it was located (not necessarily centered, but at whatever 
position it was relative to the top of the viewport).

This target cell will be used as a starting point for the layout.  I get 
the height of the target cell, and then position it as closely as I can 
to where it was last time around.  I then work my way up and down and 
add cells above and below the target cell until the viewport is filled.

If any changes in height occur, another layout should be triggered (well 
I hope atleast), and the process starts again, "centering" the target 
cell and adding cells above and below until the viewport is filled.  
This should result in the target cell being "stable" while the cells 
around it can shift positions.
> 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.
Yes I understand, I know you are very busy and I'm glad you took the 
time to have this discussion.  I'm not sure if whatever I'm cooking up 
will be contribution worthy (as I'm specifically looking at TreeView and 
vertical layouts), but if I do get it working satisfactory, we could 
take a look and see if it may be useful to you in some way.

--John