Community
Participate
Working Groups
New support for contributing views should not automatically startup the contributor's plugin if view is stacked. NOTES:
Eduardo is working on a proposal for this, as the change will affect view lifecycle. My own code, for lazy page creation, is implemented in WorkbenchPage.java, but not executed. To see, go to the second constructor for WorkbenchPage(), where deferInit is called. The restore is finished in onActivate, where finishInit is called.
Pls followup with David. Need to know definitively if there are real performance implications to this work as well as the impact on existing plugins.
Here is the two e-mail from me and David explaining why we should not change this. I would recomend to close this PR without any change. The options to solve this brings more problems then it solves and the gain it not good enough. Closing it. Please reopen if you think that work should be done or if you need more info. ++++++++++++++++++++ Eduardo Pereira 12/07/2001 03:54 PM To: David Springgay/OTT/OTI cc: Kevin Haaland/OTT/OTI@OTI Subject: Re: Defering Part Creation I have added printlns to time part creation, page creation, plugin startup as well as used optimize-it to try find the reason for implemention any of these options. I concluded that I would have the proposal to be voted and I would be the first to vote "-1". I am convinced that "Defering Part Creation" should not be implemented. Giving the user a better startup time and make him pay the price latter is not a solution. Option 1 would be easy for us to implement but would be a problem for ISV developers. Option 2 would introduce problems in the APIs like findView and getViews. The time spend writing/implementing propasals on how to do this breaking change could be better used in something else. IMO. Option 3 the current implementation is not creating the controls anyway. So the gained time is not that much. (I have timed it). The big reason not to do it is stated in DS's last 3 lines. Thanks. Eduardo. David Springgay 12/07/2001 02:50 PM To: Kevin Haaland/OTT/OTI@OTI, Eduardo Pereira/OTT/OTI@OTI cc: Subject: Defering Part Creation Hi Kevin, While you were away Eduardo investigated the idea of deferral of part creation. Then he talked with me, and we formed the following opinions. It would be incorrect to defer control creation. It would be of little value to defer part or page creation. Options: 1. Defer control creation in non visible parts. If this approach is taken, each part must perform a null pointer check in every public method. If any method is called, and the control is null, the part must implement some hack to answer the method correctly. We only see this problem for IWorkbenchPart.dispose, because we are the workbench. However, this is not a local problem. The view can be accessed at any time, just by calling IWorkbenchPage.findView. If the view has any other public methods, they must also be protected. This is not part of the view contract, and it would be a breaking change to impose it now. 2. Defer part creation in non visible parts. If this approach is taken, the page must consider "part init state" in every public method. It is not appropriate to misrepresent the parts within the page, just because we wish to defer their creation. For instance, if findView is called for a part which hasn't been created, we must create the part and return its handle. If getViews is called, we must also create all of the parts and return their handles; the result of this method should not be dependent on the init state of the page. The getViews method in particular will be called as soon as the page is visible, because we use it to populate the Perspective > Show View menu. We can implement this algorithm, but it will have no performance impact. 3. Defer creation of everything within a non visible page. If this approach is taken, we might be able to defer part creation, assuming that none of the part centric methods of the page area called. However, if the loss of context proposal is approved, we will discourage the use of multipage mode, and this change will have no impact. Regardless of whether 1, 2, or 3 is taken, the results of the optimization will be very dependent upon layout. We cannot predictably determine the improvement in start up time. We also have one big issue with the idea of lazy creation. By introducing lazy creation, we will also introduce staggered delays. For instance, it may take 5 seconds to switch to an invisible view in a tab folder. It may take 10 seconds to activate a page. From a user perspective, we are not convinced that this is an acceptable behavior. It would be better to accept the startup cost at startup time. Dave
Reopening to mark as fixed. Views, editors and perspectives are lazy initialized now.
Fixed in 2.1
