FileTreeComponent - incomplete redraw problem

Hi,

maybe i have found a bug in FileTreeComponent. i had it occasionaly to redraw itself incompletely - i.e., items were missing. i found that i can workaround it with throwing in some:

while( contentsList->isStillLoading() ) { // maybe do some dummy-operation }

in certain places. so my guess is, that it repaints itself while the embedded DirectoryContenstList is not yet fully built up. could that be? maybe some kind of callback from DirectoryContentsList to FileTreeComponent could be established to solve that in a more sound way?

btw.: the problem showed up only on OSX.

It already uses a changelistener to find out when things are added to the directorycontentslist… I can’t see any obvious flaws that might do what you’re describing - can you give any more clues?

O.K. i’ll set up an example project to demonstrate this…

so here is a demo:

http://www.rs-met.com/temp/juce_FileTreeBugDemo.zip

this is more or less the whole juce source-tree (official release 1.46) with a modified hello-world example (in extras/example_projects, the mac-osx version thereof). i could quite reliably reproduce the incomplete redraw here when doing a debug build and hitting “Build and Run”. sometimes it occurs, sometimes not. look at the constructor of class RFileBrowser - in this project, it uses a standard juce::FileTreeComponent (that is, you may ignore the other classes RFileTreeBlaBlah, etc. that are floating around here). uncommenting the dummy-loop in the constructor will make the tree draw correctly.

ah, if that means anything: i’m on OSX 10.4.11 here with a Mac Mini, Intel Core 2 Duo 2GHz, 1GB RAM

Sorry, can’t get it to go wrong here… As ever with timing-related things like this, it’s probably very specific to your machine’s speed and set-up.

Wish I could think of something else to try, but really can’t see any obvious bugs…

[quote=“jules”]Sorry, can’t get it to go wrong here… As ever with timing-related things like this, it’s probably very specific to your machine’s speed and set-up.

Wish I could think of something else to try, but really can’t see any obvious bugs…[/quote]
strange. O.K. - i have my workaround. i’ll let you know if i can find something.

hi,

I have also been experiencing this randomly without finding any repeatable pattern to reproduce it or even have the chance to debug it once.

It seems to appear more easily on mac but I’ve also seen this bug on pc.

tip: it seems to happen more easily when there’s many items and the viewport’s scrollbar is shown.

This happens to use as well. I only saw it happen in OSX so far. I have a machine running Windows and OSX, so there is no difference in specs.

I have the same problem with a TreeView (not a FileTreeComponent), but it only happens on Mac OSX and not on every machines.
For the moment, I don’t find any workaround. If someone has any idea, it will be welcome.

Same with me (with the Treeview) but I haven’t had a chance to try and debug it. Its always the last row, it flickers between clipping correctly and going invisible(depending on the scrollbar, window size), almost like a rounding error somewhere…

When I have a moment i’ll see if I can dive in a little and give Julian a little more to go on!

EDIT: The tip seems better than it was with 1.46. I am using a StretchableLayoutResizerBar and moving this(it grows and shrinks the horizontal size of the Treeview) makes the last 20 or so pixels flicker. It is probably the TreeViewItem height(I tried using the scrollbar to put the last item in as an offset)…Anyways a picture(especially a moving one) is worth a thousand words, so maybe others can chime in if this is what they are seeing as well?

(Look at the bottom left of the movie’s screen)
http://homepage.mac.com/soundminer/TreeView.mov

Ah - I bet that’s just the horizontal scrollbar briefly appearing and then getting taken away again! Some of the layout will be done asynchronously on different event callbacks, so there could be times when a repaint sneaks in there between the bar appearing and disappearing again, so you’d see it. That’d also explain why it’s different on mac/pc, because their repaint event ordering may differ slightly.

Ok - I’m a bit scared of the code that handles the scrollbar show/hide, because it’s incredibly precarious, but I’ll make a note to have a look in there again!