OK, I investigated some more. What is weird is that the same table cell instance (I checked the Object hashcode) is set to different model values while it is still visible, i.e. I get sequences like this in the log, just when I display the table:
Updating cell 673139775 from null with Image reference for Row 0 Adding Row 0 to image load queue Updating cell 673139775 from Image reference for Row 0 with Image reference for Row 1 Adding Row 1 to image load queue Dequeueing image for Row 0 Updating cell 673139775 from Image reference for Row 1 with Image reference for Row 2 Adding Row 2 to image load queue Dequeueing image for Row 1 Updating cell 673139775 from Image reference for Row 2 with Image reference for Row 3 Adding Row 3 to image load queue Dequeueing image for Row 2 Updating cell 673139775 from Image reference for Row 3 with Image reference for Row 4 Adding Row 4 to image load queue Dequeueing image for Row 3 Updating cell 673139775 from Image reference for Row 4 with Image reference for Row 5 Adding Row 5 to image load queue Dequeueing image for Row 4 Updating cell 673139775 from Image reference for Row 5 with Image reference for Row 6 Adding Row 6 to image load queue Dequeueing image for Row 5 This means that I cannot rely on the same table cell to be used for displaying the content while its row is visible (+ a bit of buffered rows around the visible area) and that means the whole approach will not work. It would really be great if someone from Oracle could comment here. None of this behaviour is documented in the API so it seems that using this is really relying on implementation details and I have found any other options to achieve that. The behaviour of the application as it is now is that randomly some images are never loaded, because they are quickly removed from the load queue because the cell's content is overwritten while it is still being displayed. On Wed, Jan 28, 2015 at 5:17 PM, Robert Krüger <krue...@lesspain.de> wrote: > Yes, and I think there was a mistake in my code. I have it almost working > and have to analyse now, why it does not work for all cells, which may > again be my mistake. I will investigate and post an update and if I don't > find it, I will build a simple test program to illustrate this. > > On Wed, Jan 28, 2015 at 5:06 PM, Werner Lehmann < > lehm...@media-interactive.de> wrote: > >> That's strange because then TableView would have to create cells always >> new instead of reusing them - if they would be reused you would see the >> updateItem calls you are saying do never occur... As far as I know the >> number of cells is about as many as you need for one visible page in the >> tableview plus 2-4 more to facilitate scrolling. >> >> >> On 28.01.2015 15:47, Robert Krüger wrote: >> >>> To clarify: I am using the stack approach you describe and I remove it >>> from the stack when updateItem for a table cell is called that already >>> has a different item set. Then I remove the already set item from the >>> stack but that never seems to happen in my example. >>> >> >> > > > -- > Robert Krüger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com > -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com
