Hi Mark,
Thanks for your help. I've discovered that the problem is actually in
PDT, when using the built in Eclipse 'Navigator' view, the decorations
don't flicker. It only does so within the 'PHP Explorer' view in PDT.
Sorry for the wild goose chase... for an end-user, it's sometimes hard
to tell what plugin is responsible for what in Eclipse! :-)
Thanks for your prompt help anyway, I'll take the problem to the PDT guys.
Cheers
Tom
Mark Phippard wrote:
> On 9/6/07, Tom Walter <tom.walter@hitwise.com> wrote:
>
>> Hmm. Thanks for the tip however cleanup doesn't stop it. There is about
>> 4000+ files in the project, I guess maybe it is an eclipse platform issue,
>> asking subclipse to redecorate unneccessarily, and the redecoration just
>> takes a long time because I am computing deep status on such a large number
>> of files.
>>
>> Thanks anyway.
>>
>> If I were to put in a feature/bug report somewhere to have someone check
>> why eclipse is requesting redecoration on files that haven't changed, which
>> project would that be best in, Eclipse Platform?
>>
>
> Probably Platform, maybe Team. My guess is that it does this check to
> accommodate tools that are doing pessimistic locking as the state of
> the file may have changed. Have you actually turned off that
> preference and seen the flickering go away? My understanding is that
> the Subclipse cache management had gotten very fast and efficient. It
> is not like we scan all 4000 files.
>
> The decorator code works off a cache and the cache gets told by
> Eclipse when something has changed and needs to be refreshed. So not
> really sure why you are seeing this.
>
> Maybe you could replicate it with a large public project, like
> something in the Apache project repository? If so, then that would
> give me and other devs a chance to try to recreate the issue and see
> if there are more optimizations to make.
>
>
Received on Tue Sep 11 02:27:55 2007