Re: [platform-ui-dev] Makeing the compat layer perform

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Tom, thanks for all this. Here's my two cents....

For me one place to start is to remove our use of SWT.DEFER on layouts, it's causing more harm than good. Since removing them will undoubtedly cause some layout regressions part of the work should be to look at and optimize *all* the layout calls.

Managing the recursiveness of the CSS is also necessary. From what we saw from the Control Center problems at eclipsecon last year it seemed that most of the CSS activity occurred because of activation so perhaps we could just not automatically style on activation and have code where needed to style only the widgets it needs to (for example when a stack goes active the CTF does need to style itself but I don't know of any editor / view hosted in a tab that changes its own look when active, do you ?). You would still pay the cost of a fully recursive styling on the initial render but not on every activation change.

Back to Orion,
Eric


Tom Schindl ---02/25/2015 01:35:10 PM---Hi, I've been with a customer this week and we tried to get a really really

From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, platform-ui-dev@xxxxxxxxxxx
Date: 02/25/2015 01:35 PM
Subject: [platform-ui-dev] Makeing the compat layer perform
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

---

Hi,

I've been with a customer this week and we tried to get a really really
big form based application running on Mars M5a and while we could get
things up and running there've been subtle bugs and a big performance
loss on things like perspective switching when you have many many controls.

So let's start with the subtle things:
* Activities did not work when one used stack in the
  perspectiveExtension [released fixed with 460414]

* Publishing postselection events did work only after the part had been
  activated at least once [released fix with 460600]

* We never call WorkbenchWindowAdvisor#postWindowRestore which has been
  reported before already as 450541. A gerrit review is pending but I'd
  like Paul, Dani or wh ever thinks knows enough about this ares to
  review it https://git.eclipse.org/r/42423

Now let's get to the less subtle stuff causing stuff anyone will see on
first sight when running an 3.x application on 4.x. Performance degrades
to a point where the UI is unusable.

* Equinox freaks out when you have many bundles doing reexports. Pre
  Luna Equinox 2secs, Luna ~20secs for uncached starts, cached starts
  worked as before. We fixed that by removing the reexports who are a
  bad idea anyone agrees anyways.

* The CSS Engine is freaking out causing big performance regressions
  when there are many child controls. Just run the application on
  460840 to see what I mean

* We are sending bogus part-activations when switching perspective. I
  guess it's not only RCP application that get affected by this. The
  problem is reported as 460835 and we came up with a fix but this is a
  very critical thing and others need to look at it. See
  https://git.eclipse.org/r/42677

* platform code as well as SWT-CTabFolder do layouts like
  layout(true,true) on shells and parent containers at will causing a
  freaking number of unneeded layouts. We identified them as:
  - [Bug 460744] New: CTabFolder forces relayout on parent when tab is
    added

  - [Bug 460747] New: Perspective switching does not appropriately
    layout shared components with MinMaxAddon

  - [Bug 460748] Compatlayer code schedules layoutDeferred calls on
    main shell who result in a complete relayout on perspective switch

  where both of them make no real sense. It's unclear what problem
  460744 should solve, do we really want to relayout all siblings if a
  tabfolder gets a new item - in the eclipse perspectives this means
  you layout ALL currently visible tabfolders including ALL of their
  children containers (visible or not is not important - see 460745 for
  a request to fix this IMHO stupid behavior)

  The "winShell.layout(true, true);" in 460747 fixed for you (maybe
  with knowing it does it) the problem when you are switching
  perspectives and you need to reposition shared elements like the
  editor-area but the real fix getting us an unbelieveable performance
  boots on perspective switching is in the gerrit patch we provided as
  https://git.eclipse.org/r/42605

To summerize:
* 460414 fixed
* 460600 fixed
* 450541 - review pending
* 460840 - no idea how to fix, work around for 3.x apps ported is to
           run with -cssTheme none
* 460835 - review pending, might affect IDE as well, IMPORTANT FIX!
* 460744 - waiting for SWT to comment but curcial to get performance
           back to an acceptable level and the code IMHO makes no sense
           at all
* 460747 - review pending, might fix IDE problems, IMPORTANT FIX!
           because with only this fix we can get acceptable (not good)
           performance if even if SWT does not react
* 460748 - not sure we can get rid of these calls but given we can get
           460747 this does not cause as much problems as of today
* 460745 - generally speaking a nice to have because e.g. only the
           active child gets relayout when you resize the parent so why
           do you unconditionally layout all children?


Tom

-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev