Community
Participate
Working Groups
See class org.eclipse.jface.text.TextViewerHoverManager Method: computeInformation() The call to hover.getHoverRegion(fTextViewer, offset); is done on the UI thread. However the only part needs UI thread is JFaceTextUtil.computeArea(region, fTextViewer); I propose 1. move hover.getHoverRegion(fTextViewer, offset); off the UI thread under fThread 2. Move widget hover area calculation (JFaceTextUtil.computeArea(region, fTextViewer);) under fThread but wrap it inside the Display#asyncExec and wait for the resultant area to be computed on the UI thread. Gerrit patch for the proposal is coming.
Language server protocol computes the hover region (text region) and hover content on the language server process side. (LSP4J and LSP4E projects) Therefore, it'd benefit if calculations that might be done outside of Eclipse process would be moved off the UI thread where possible.
New Gerrit change created: https://git.eclipse.org/r/145344
I'm not sure it's really something we can change at this point in existing hover strategy (see comment on Gerrit). I think we need to workaround it in LSP4E instead (returning some dummy good enough value in case operation take too long)
Yes, I agree moving something off UI thread is indeed an API breakage... Wonder if we could still do something like what i proposed without breaking the API... For example TextViewerHoverManager asks the text viewer for ITextHover... Perhaps we could add a new method to the interface ITextHover called isAsync() and if it returns true perform calculations off the UI thread (except widget area). Otherwise, if not async proceed with calculations exactly as before thus not breaking the API. The method could be introduced to the interface with default implementation returning false. The ExtensionBasedTextViewerConfiguration can create a subclass of CompositeTextHover where isAsync() returns true and LSBasedHover would also return isAsync() true. What do you think?
(In reply to Alex Boyko from comment #4) > What do you think? This is the right path IMO. However, since we see more and more occurrences of this problem (moving as much computation as possible out of UI Thread), I think a common solution need to be chosen by Platform at large rather than a Generic Editor specific workaround. I've started a thread on this topic on platform-dev@eclipse.org.
See bug 548970 about a common way to declare UI Thread isn't required. Once we have this is (or something similar), we can rework the hover mechanism to check for that and go to another thread when possible.
I'll close this as wontfix then
