Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Open Editor timeouts

Thanks Ed Merks for the clarification. 

One small clarification from my side:

> I must also say that personally I'm finding the UI freeze dialogs themselves the thing that is generally blocking and disrupting the UI in cases where I have no real personal perception that something > is frozen.  Certainly shipping with this type of behavior will result in it generally being turned off, or in a ridiculous flood of bugzillas.

If I'm not mistaken Ed Willink refers to the new UI freeze monitor in platform.ui. This monitor can be enabled / disabled in the preferences (see screenshot) and will not open an dialog by itself, it will just write an error log entry in case a freeze is detected. The automatic error reporting from Marcel can pick this freeze up, which may result in a dialog. EPP for committers enables this by default so that we (the Eclipse developer community) can get the information where we have freezes. AFAIK their are no plans to enable this for other EPPs.

Best regards, Lars



2014-12-03 9:05 GMT+01:00 Ed Merks <ed.merks@xxxxxxxxx>:
Ed,

Only the editors know what it is they're doing and the division between what should be done on the UI thread (creating widgets/controls), what could/should be deferred, and how that deferral as well as progress is reflected in the UI doesn't sound like something for which the platform can just provide a generic solution.  At best some type of scaffolding/framework, but that's not a prerequisite for solving the problem.  For example, for Oomph we load resource sets that contain a very large number of internet hosted resources, but the performance of that is generally so bad that we must take steps to do that on a background thread, i.e., it's not just 2 or 3 seconds but rather several 10s of seconds.  So we do several things:
  •  Keeping local caches of remote resources with etag/timestamp checking to reduce internet traffic.
  • Loading resources in parallel on many threads (because internet loading is mostly waiting for a response, so 10 parallel requests will generally produce results 10 times faster).
Of course it would be nice to feed this type of stuff back into EMF...

I must also say that personally I'm finding the UI freeze dialogs themselves the thing that is generally blocking and disrupting the UI in cases where I have no real personal perception that something is frozen.  Certainly shipping with this type of behavior will result in it generally being turned off, or in a ridiculous flood of bugzillas.



On 03/12/2014 8:44 AM, Ed Willink wrote:
Hi Lars

I think you're agreeing with me and identifying a useful criterion for must-use-Worker.

But while it's not a platform problem, only a platform solution makes sense. Why should many editor projects develop similar use-worker-to-open strategies? Much better at the platform level where there might even be integration with changing project dependencies during a slow open.

    Regards

        Ed Willink
   
On 02/12/2014 21:07, Lars Vogel wrote:
Hi Ed,

If an editor accesses the Internet I think it should use a worker thread to get the editor content. I have not seen reports for platform editor freezes, AFAIK the platform editors do not access the Internet for their content. 

I would think this is not a platform problem, an editor is IMHO responsible to get his data model and I'm unware of special support in the platform for asynchronous editor loading.

Best regards, Lars

2014-12-01 18:34 GMT+01:00 Ed Willink <ed@xxxxxxxxxxxxx>:
Hi

The Code Recommender's reports highlight a cross-project phenomenon that is difficult to allocate to a particular project.

If an editor is slow to open, the current opening strategy on the UI thread can lead to a UI freeze.

For platform editors, the 2s timeout may just be adequate, so, not a platform problem.

Bug 453590 causes the basic Ecore Editor to timeout if a user gives a stupid URI causing Internet failures.

By the time we get to Xtext and worse still my OCL Xtext editors, there is ample scope for opening to take more than 2 seconds.

I'm getting irritated by the number of UI freeeze duplicates and could attempt to override the platform/Xtext editor strategies to put up a loading welcome page while a worker thread does the necessary.

But I feel that provision of such a strategy is really a platform job rather than my job three levels of abstraction further on.

Is anyone else seeing this as a problem?

    Regards

        Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4235/8669 - Release Date: 12/02/14




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Attachment: uifreeze.png
Description: PNG image


Back to the top