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

[Tom Schindl]

I think this whole discussion moved away from the real API review we
requested or did I miss how the stuff discussed here would modify the API?

So can we get back to discussing this API and get approval or
disapproval so that we can move on getting it fixed for JFX8.

Tom

Am 05.02.13 08:23, schrieb 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
> 


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834