Mark selected treeitems with "focused" attribute when tree is focused

RESOLVED WONTFIX

Status

()

Core
XUL
P3
normal
RESOLVED WONTFIX
17 years ago
9 years ago

People

(Reporter: Joe Hewitt (gone), Assigned: Joe Hewitt (gone))

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
This is needed to optimize our css.  Currently, we need to use the famously
inefficient descendant selector in order to draw a border around selected
treerows when a tree has focus, like this:

tree:focus > treechildren treeitem[selected][current] > treerow

I suspect that this rule is partially to blame for the super-slow style
resolution in mail when you switch the focus amongst the 3 panes.  The way to
solve this is to mark the selected treerows with a "focused" attribute when the
tree is focused, and remove it when it's not.

I've run some tests with and without these selectors in mail, and there seems to
be a slightly perceptible speed increase without them.  It's hard to really
gauge though, since my workstation is fairly quick.

attinasi/hyatt, do you think this is even worth the trouble, or is the time to
mark all selected rows with a new attribute not any better than the algorithm
currently used to resolve a descendant selector on a large tree?

Comment 1

17 years ago
If you can change the selector
  tree:focus > treechildren treeitem[selected][current] > treerow
to
  tree:focus treerow[focused]

then you will make style resolution much faster, for sure. I have no idea what
it takes to set and clear the "focused' attribute on the treerow, however, so it
is unclear if this is a net win or not. The problem with the selector matching
algorithm is that it tries to match from the bottom up, so you pay the price of
the selector matching on all treerows (until the matching fails anyway). Marking
each treerow will only affect the currently selected and deselected rows, right?
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P3

Comment 2

17 years ago
I am not sure this needs to be done.  My profiles of focusing the tree revealed
the problem to be more with pseudo matching than with the > selectors.  I think
it would be more accurate to have a bug with the summary "Focusing trees in
mail/news is slow", and then we can profile and discuss the various options.

Comment 3

17 years ago
The cost can also vary based off of what's being blurred.  You're switching
between two objects usually, and so you have to consider that you're potentially
doing style re-resolution on two trees, not one.

(Assignee)

Comment 4

17 years ago
The problem I was referring to isn't with the ">" child selector, it's with the
" " descendant selector -- have you noticed any slowdown with regard to this
selector?

Comment 5

17 years ago
Not really, since the descendant selector only occurs to the left of selected
tree items.  If you can whip this up to experiment, though, it might be worth
trying.

I'm just nervous about it, because in the case where you have all your messages
selected, you could be setting thousands of attributes on a focus.  THere is a
point at which the cost of setting a bunch of attributes far outweighs the cost
of crawling up only in the selected row case.

Updated

17 years ago
Keywords: perf
(Assignee)

Comment 6

17 years ago
don't think this will be necessary
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Updated

9 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.