Bug 491334 - [CSS] Improve CSS Engine performance
Summary: [CSS] Improve CSS Engine performance
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.6   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 501608
  Show dependency tree
 
Reported: 2016-04-08 10:42 EDT by Brian de Alwis CLA
Modified: 2019-02-11 06:41 EST (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Brian de Alwis CLA 2016-04-08 10:42:58 EDT 
A bug to gather small improvements to the CSS engine performance
Comment 3 Eclipse Genie CLA 2016-09-15 04:22:28 EDT 
New Gerrit change created: https://git.eclipse.org/r/81151
Comment 5 Eclipse Genie CLA 2016-09-18 09:37:48 EDT 
New Gerrit change created: https://git.eclipse.org/r/81293
Comment 7 Mickael ADAM CLA 2016-12-01 10:04:23 EST 
Hi we have a regression in Papyrus (bug 508537) due to the commit 878e1f005bc16bd65c6ec9aa3c55d6b305280b3c (https://git.eclipse.org/r/70826)

Before the change E[foo] was returning false when the foo attribute was null, but now it's true.

[1] say that: "E[foo]	Matches any E element with the "foo" attribute set (whatever the value)." So for me, when foo==null, foo is not set, so match(..) should return false?

See the actual code:

         /**
	 * Tests whether this condition matches the given element.
	 */
	@Override
	public boolean match(Element e, String pseudoE) {
		if (!e.hasAttribute(getLocalName())) {
			return false;
		}
		String val = getValue();
		if (val == null) {
			return true; //To be change by false here
		}
		return e.getAttribute(getLocalName()).equals(val);
	}


[1] - https://www.w3.org/TR/CSS2/selector.html#pattern-matching
Comment 8 Eclipse Genie CLA 2016-12-01 10:12:51 EST 
New Gerrit change created: https://git.eclipse.org/r/86156
Comment 9 Mickael ADAM CLA 2016-12-01 10:58:20 EST 
It's appears that the link provide in https://git.eclipse.org/r/70826: the [1] is related to CSS2 with this definition:

   E[foo] : Matches any E element with the "foo" attribute set (whatever the value).

In CSS3 [2] we have this definition:

   E[foo] : an E element with a "foo" attribute.

Which is not th same thinks. In CSS it appears that the "foo" attribute  does not need to be set. In this case it's our test which is in fault.

Which version of CSS Oxygen is compliant ?



[1] - https://www.w3.org/TR/CSS2/selector.html#pattern-matching
[2] - https://www.w3.org/TR/css3-selectors/
Comment 10 Brian de Alwis CLA 2016-12-01 11:17:55 EST 
Our CSS is based on Apache Batik's CSS engine, which is CSS2.
Comment 11 Eclipse Genie CLA 2017-02-15 04:42:46 EST 
New Gerrit change created: https://git.eclipse.org/r/91120
Comment 13 Brian de Alwis CLA 2017-05-26 09:49:45 EDT 
I was chatting with a Mozilla contributor a while back, and asked about some of the performance optimizations they do for applying CSS.  They use multiple threads to walk the DOM and schedule CSS changes.  I realized one issue we face is that our SWT CSS engine doesn't have sole custody over the widget hierarchy (i.e., user code can and does make changes) so we can't assume our spoofed up DOM elements hold the truth, and so processing must be done on the SWT thread.
Comment 14 Lars Vogel CLA 2019-02-11 06:41:24 EST 
Please open new bugs if you see more options to improve CSS performance