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

Bug 313950

Summary: CSS Engine creates unnecessary contexts and injections
Product: [Eclipse Project] e4 Reporter: Oleg Besedin <ob1.eclipse>
Component: UIAssignee: Bogdan Gheorghe <gheorghe>
Status: RESOLVED FIXED QA Contact: Bogdan Gheorghe <gheorghe>
Severity: normal    
Priority: P3 CC: ob1.eclipse, s.muecke
Version: unspecified   
Target Milestone: 1.0 RC2   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Illustrative patch - not meant to be applied - just shows the problem
none
Patch
none
go back to Method.invoke
none
Back to Reflection! none

Description Oleg Besedin CLA 2010-05-21 13:43:19 EDT
Created attachment 169530 [details]
Illustrative patch - not meant to be applied - just shows the problem

About 30% of the time we spent to switch between the editors is spent in injection and processing of CSS attributes.

1)
The CSS engine methods, such as CSSPropertyInnerKeylineSWTHandler#applyCSSProperty() seem to create unnecessary contexts on every editor tab switch.

The common pattern for AbstractCSSPropertySWTHandler is:

IEclipseContext childContext = context.createChild();
childContext.set("innerKeyline", newColor);
ContextInjectionFactory.inject(renderer, childContext); 

I don't know the surrounding code, but unless it is doing something very special, the following woudl do the same:

((IEclipseContext) appContext).set("innerKeyline", newColor);

without creating a new child context and injecting it.

I'll attach an illustrative patch were I changed a few classes.

====
2)
The other strange thing is CSSPropertyTabRendererSWTHandler#applyCSSProperty(). That method is called several of times on tab switching (6 times for my compatibility workbench), and every time it creates a new context, a new CTabFolderRenderer class, and injects the new context into that new class.
Comment 1 Bogdan Gheorghe CLA 2010-06-30 13:05:18 EDT
Created attachment 173128 [details]
Patch
Comment 2 Bogdan Gheorghe CLA 2010-06-30 13:06:03 EDT
Fixed in HEAD > 20100630
Comment 3 Oleg Besedin CLA 2010-07-06 11:36:26 EDT
See bug 318946 comment 5, bug 318798 comment 8.
Comment 4 Boris Bokowski CLA 2010-07-06 11:47:04 EDT
Created attachment 173573 [details]
go back to Method.invoke

This patch doesn't work quite right yet but it shows what I think we should do for 4.0.
Comment 5 Oleg Besedin CLA 2010-07-06 11:57:17 EDT
(In reply to comment #4)
> Created an attachment (id=173573) [details]
> go back to Method.invoke
> This patch doesn't work quite right yet but it shows what I think we should do
> for 4.0.

Hmm... that looks strange :-). We should #invoke() once, when the object is created and then simply change values in the context.
Comment 6 Oleg Besedin CLA 2010-07-06 13:12:17 EDT
That should have being "#inject()"; not "#invoke()".
Comment 7 Oleg Besedin CLA 2010-07-06 13:36:35 EDT
*** Bug 318798 has been marked as a duplicate of this bug. ***
Comment 8 Bogdan Gheorghe CLA 2010-07-07 18:14:25 EDT
Created attachment 173721 [details]
Back to Reflection!
Comment 9 Bogdan Gheorghe CLA 2010-07-07 18:31:33 EDT
Fixed in HEAD > 20100707