Little worried about the ListView/TreeView/TableView classes

[Jonathan Giles]

Comments inline.

-- Jonathan

On 11/07/2012 5:38 a.m., John Hendrikx wrote:
> Hi Jonathan,
>
> I'll do what can to help get some of these resolved, so I have filed 
> three new issues (all using the same sample code), RT-23331,  RT-23332 
> and RT-23333 which address three of the problems below.  Some of the 
> others I already created issues for, the most critical of those 
> (causing graphics glitches) is a solution for this one:
>
> RT-22555 Unpredictable behaviour with scrollTo and the view classes 
> (TableView as example)
>
> It causes rendering to fail -- for Scenes that are fairly static this 
> can mean some controls are simply invisible until the user tries 
> interacting with them.  The provided sample is brute-force code to get 
> this to occur, but it happens in normal use of my app (especially when 
> only layout is changed and some controls are swapped out, ie, a 
> TreeView becomes a TableView to show items in 2 columns -- in those 
> cases all data is loaded already and the change can happen very fast 
> -- when more processing still needs to occur (like images being loaded 
> causing item changes) it doesn't happen.. or it simple hides the 
> problem because of a redraw occuring).
I've noted a simplistic workaround to this problem in the jira issue. 
Basically, you're trying to modify the state of UI controls before they 
are in a scene, which is not very well defined.
>
> Then there several issues dealing with Cell creation:
>
> RT-22946 TreeView creates cells for every item from start to scrollTo 
> position
> RT-20892 Layout pass of TreeView can result in unneccessary recreation 
> of TreeCells
> RT-20616 TreeView creates new cells every time root is changed
>
> The first one is the most problematic because it creates lots of cells 
> but more importantly.. *different* cells.  The other two are less of a 
> problem since atleast they donot cause data to be accessed that is not 
> going to be displayed.
I've definitely got a few performance issues with 
TreeView/ListView/TableView, but I wasn't about to try and fix them at 
the end of the 2.2 development cycle (it's just too risky). Instead, I 
hope to look at these issues very early in the next release cycle. I'm 
more than happy to work with others on developing fixes via openjfx 
though! :-)
>
> The issue with creation of a ListView and using it immediately (with 
> select/focus/scrollTo calls) is captured a bit in RT-22555 as well I 
> think, resolving that will probably resolve these issues as well.
I'm not too sure whether you're referring to another jira issue here?
>
> And there's two minor issues I filed related to these classes as well:
>
> RT-20879 After setting new root on TreeView, focus model's focused 
> item property is not updated
> RT-22398 Some navigation keys (pg-down/up, etc) donot work until 
> TreeView/ListView/TableView item has both focus AND is selected
I've asked for further feedback on these two issues in Jira - I'm 
awaiting your response.
>
> For some of these it is rather hard to create good small test programs 
> -- there appear to be timing issues with some of them (whether the 
> ListView has already been rendered atleast once or not yet, and/or 
> whether it was added to a Scene or not). Sometimes putting things like 
> select/focus/scrollTo in a Platform.runLater() makes the issue worse 
> or better.
Platform.runLater is unfortunately not a solution (as you note). The 
primary issue really is whether a node is part of a scene before you run 
operations on it, and whether you're running operations in the JavaFX 
application thread.
>
> I can provide help in the form of trying to write test cases for 
> problems that you cannot reproduce at all.  The three most annoying 
> bugs are:
>
> RT-22555 (causes graphic glitches)
> RT-22946 (makes large lists slow to display when scrolling to a high 
> index in the list when restoring last cursor position)
> RT-23331 (graphics glitch where user cannot see the highlighted item)
I've commented about RT-22555.
RT-22946 falls into the bucket of perf fixes I hope to do early in the 
next release cycle.
RT-23331 seems to relate to a custom written skin. I would be very 
interested if there are any issues when using the provided default skins.
>
> The rest are annoying but only waste some resources or are minor gfx 
> glitches or have work-arounds.
>
> If there is anything I can do to make these easier to solve, I can 
> work on that in the weekend/evenings.  I'll upgrade to the latest beta 
> tonight to see if any of them happened to have been resolved.
Another thing you can consider doing is pulling the latest openjfx 
mercurial repo code and attempting to develop fixes - all the controls 
source is open. You never know, you might be able to fix some of these 
bugs :-)
>
> --John
>
> On 10/07/2012 01:02, Jonathan Giles wrote:
>> I'm happy to help work through these issues to try to find fixes 
>> (which may be able to get into 2.2) or find workarounds, although it 
>> is probably easier to have a discussion on each of the jira issue 
>> pages, rather than grouped together in an email (both for ease of 
>> discussion, and so we can have a record of what was said).
>>
>> Chances are all these bugs are already assigned to me. If so, lets 
>> start working through these right away. If not, email me the bug 
>> report numbers and I'll add myself as a watcher (or take ownership of 
>> them as they are likely my bugs anyway).
>>
>> -- Jonathan
>>
>> On 10/07/2012 10:51 a.m., John Hendrikx wrote:
>>> My program relies extensively on the *View classes, however, there 
>>> are numerous little problems with these (JavaFX 2.2b13) that I'm 
>>> considering rewriting these controls myself to "take control" and 
>>> being able to fix problems.
>>>
>>> Many of the issues I've reported as bugs, which are all in the 
>>> process of being deferred to JFX3.0 (if I understand correctly), 
>>> which is scheduled for over a year from now.
>>>
>>> Here is a list of problems I've been running into just this past 
>>> week -- and I've reported several others.  Most of these apply to 
>>> any of the *View classes, but some may be specific to one of the types.
>>>
>>> - Calling requestFocus() behaves differently from clicking with 
>>> mouse/tabbing when
>>> using only keyboard navigation:
>>>
>>> Left Mouse Click:
>>> Current focusowner : VirtualFlow[id=virtual-flow, styleClass=]
>>> Current focusowner : ListView[id=null, styleClass=list-view]
>>>
>>> Tabbing to it:
>>> Current focusowner : ListView[id=null, styleClass=list-view]
>>>
>>> Programmatic requestFocus() immediately after ListView added to Scene:
>>> Current focusowner : ListView at 1966198[styleClass=list-view]
>>>
>>> Why is it not the same?  This seems to be causing issues sometimes 
>>> where the ListView
>>> is not properly activated and it is not accepting keyboard input 
>>> (despite being the
>>> focusowner as printed above).
>>>
>>> - Sometimes ListView starts highlighting every Xth cell when 
>>> scrolling through list
>>>
>>> Scrolling through a ListView using the cursor keys one can get the 
>>> ListView stuck to
>>> highlighting only the Xth cell (where X seems to be in the range of 
>>> the number of active
>>> Cells).  When there is only few items in the list this bug manifests 
>>> itself as not
>>> changing the focus of the item at all (ie, the wrong cell is 
>>> highlighted).  Usually a
>>> mouse click on a random item fixes this bug again, but sometimes 
>>> even that doesn't work.
>>>
>>> This bug is incredibly hard to reproduce but the frequency of it can 
>>> be increased
>>> by using a ScrollBar Skin that breaks the rule that getNode() should 
>>> always return the
>>> same item.  It however happens with the default ScrollBar Skin as 
>>> well, just much much
>>> rarer.  I have a test case with a contract-breaking ScrollBar Skin 
>>> that manages to
>>> reproduce it almost every time.
>>>
>>> - Page up broken when used at bottom of ListView
>>>
>>> Scroll down fully with page down.  Now page up, notice that it goes 
>>> up one page, but the
>>> next page up only goes up one item for a few times (about a page 
>>> worth of items) before
>>> starting to act like a real page up again.
>>>
>>> - Pressing Cursor Left/Right on an active ListView changes focus 
>>> despite keys being consumed
>>>
>>> Despite having a handler in setOnKeyPressed that consumes the Cursor 
>>> keys (to do something
>>> useful with them) the focus still also changes (ie, it triggers my 
>>> action AND affects
>>> a focus change).  I can block them with an EventFilter, but would 
>>> rather allow users of
>>> my custom control to still being able to register these keys for 
>>> special purposes...
>>>
>>> - Numerous scrollTo bugs
>>>
>>> Poor centering when scrolling to an item (sometimes even outside 
>>> view port); not responding
>>> at all when called at inoppertune times (right after populating and 
>>> adding to scene); unable
>>> to precisely save/restore view position; creating cells for every 
>>> item from 0 to item being
>>> scrolled to... and recently (since 2.2betas) completely failure to 
>>> draw the ListView at all
>>> (can take various forms, only scrollbars drawn, somtimes the entire 
>>> container is missing).
>>> Restores itself on any ListView redrawing activity, like selecting 
>>> cell, scrolling with cursor
>>> keys, etc..
>>>
>>> - Numerous focus/select bugs
>>>
>>> Similar to above, when these things occur in rapid succession 
>>> (ListView added to Scene,
>>> populated, correct item selected, scrolled to saved position) it 
>>> happens frequently that no
>>> cell gets highlighted at all (or perhaps the wrong one is 
>>> highlighted but not visible at
>>> the current scroll position)
>>>
>>> - Cells are sometimes a pixel different in height
>>>
>>> Haven't been able to find a pattern to this yet, it happens with the 
>>> default cell renderer
>>> when it is styled with some fancy borders.  Very noticable when 
>>> holding cursor down because
>>> the borders jitter (create a border with an inset of 1 or 2 pixels 
>>> so there should be a fixed
>>> gap between the cells, the gap will sometimes be a pixel larger than 
>>> usual).
>>>
>>> It doesn't seem to be content related as a cell that is a pixel too 
>>> large in the upper half
>>> of the ListView can appear regular size in the bottom half of the 
>>> ListView.
>>>
>>> ....
>>>
>>> There are probably more I forgot to list or already worked around 
>>> and forgot about (I seem
>>> to remember constructing a ListView, not adding it to Scene, but 
>>> populating it and selecting
>>> an item and calling scrollTo, and THEN adding it to the Scene works 
>>> very poorly as well).
>>>
>>> Anyway... I'm a bit worried that fixes for these are now over a year 
>>> away... I don't really need
>>> much (just a scrollbar, some same height, same width custom cells, 
>>> nicely stacked on top of each
>>> other reacting to cursor input) but I just keep running into above 
>>> problems during normal use
>>> of the app.
>>>
>>> Can I help get these debugged or am I on my own?
>>>
>>> --John
>>>
>>
>>
>