Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 311073

Summary:	[CommonNavigator] Support NON-UI thread load of content providers?
Product:	[Eclipse Project] Platform	Reporter:	Chuck Bridgham <cbridgha>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	bokowski, francisu, mcraquel, melickm, pwebster, thatnitind
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Chuck Bridgham

2010-04-29 13:30:56 EDT

This is more of a question, and if not a request for support.

In some scenarios, large workspaces can cause content providers to be delayed while returning their children content.  Because the common navigator is being refreshed on the UI thread, the delay feels like a UI hang - sometimes taking several seconds to part of a minute.

Some content providers recognize this issue, and provider "placeholder" support, where a dummy node/child are returned while a separate background job does the real work of collecting the child contents.  After the job finishes, the node is replaced and refreshed.

A more brute force approach for the Navigator could be calling every content provider getChildren() on a separate Non-UI Job, and generically returning a placeholder, while the contents are being collected in the background.

Any feedback is welcome, and I would be happy to collaborate on a solution

Comment 1 Francis Upton IV

2010-04-29 13:50:22 EDT

I think this is a very interesting idea. Seems like it should be an option (as oppose to paying the thread switch all of the time), and it might be something to look at in conjunction with the virtual tree support (these might not be entirely related but perhaps similar mechanisms can deal with both cases).

An interesting question is when to decide to do it on another thread. Certainly, as you point out, some content providers can make the decision on their own, but if there are lots of unrelated content providers, then perhaps when aggregated it takes too much time. Maybe there should be a heuristic or something?

Comment 2 Chuck Bridgham

2010-04-29 14:48:02 EDT

Can you give me a bug # for the virtual tree support?   Is this a TreeViewer that can be populated on a non-UI thread?

Comment 3 Chuck Bridgham

2010-10-13 13:37:09 EDT

Wanted to get a prognosis on this enhancement request.  We could donate some time for this enhancement, and in my mind is very high priority from a performance/usability standpoint.

Most initial actions originate from the common navigator (tree expansion, context menu etc..)  Having the ability to transfer some of the worst performing content providers onto a background thread would keep the workspace responsive, and generally give a better user experience.

Comment 4 Francis Upton IV

2010-10-13 14:03:30 EDT

(In reply to comment #2)
> Can you give me a bug # for the virtual tree support?   Is this a TreeViewer
> that can be populated on a non-UI thread?

bug 130221

Comment 5 Francis Upton IV

2010-10-13 14:04:55 EDT

(In reply to comment #3)
> Wanted to get a prognosis on this enhancement request.  We could donate some
> time for this enhancement, and in my mind is very high priority from a
> performance/usability standpoint.
> 
> Most initial actions originate from the common navigator (tree expansion,
> context menu etc..)  Having the ability to transfer some of the worst
> performing content providers onto a background thread would keep the workspace
> responsive, and generally give a better user experience.
I would be happy to entertain a patch for this and work with someone on creating it. I don't have much time right now to devote to CNF issues, but if someone wants to work on this I can help them. Perhaps some sort of design notes about how to proceed and how this relates to bug 130221 would be a good start.

Comment 6 Lars Vogel

2019-11-14 03:32:43 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.