Little worried about the ListView/TreeView/TableView classes

Tue Jul 10 10:38:23 PDT 2012

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).

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.

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.

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

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.

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)

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.

--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
>>
>
>