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 <[email protected]
<mailto:[email protected]>>:
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
[email protected]
<mailto:[email protected]>
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
[email protected]
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 <http://www.avg.com>
Version: 2015.0.5577 / Virus Database: 4235/8669 - Release Date: 12/02/14
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
