Drop-down lists take too long to show

VERIFIED WORKSFORME

Status

()

P2
normal
VERIFIED WORKSFORME
19 years ago
18 years ago

People

(Reporter: cpratt, Assigned: pierre)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
Build ID: 1999082008
Platform: Windows NT (Behavior is OK on Linux; Mac OS build currently bad)

To reproduce:
- Launch apprunner
- Load the above URL (Netscape internal only) or the attached test case
- Drop down the drop-down list displayed on the page

Result: It takes upwards of 3 seconds on a Pentium with MMX, 200 MHz, running
Windows NT 4.0 SP 5. This is an unacceptable length of time.

Note: This test page (which can be found it its original form at
mozillazine.org) has 5 tables nested within each other. If you take the FORM out
of the tables, performance is markedly improved.

From the DOS window: 123 Position Dropdown at: 0 330 1110 480
nsComboboxControlFrame::Reflow 143   Reason: eReflowReason_Incremental
nsComboboxControlFrame::Reflow 144   Reason: eReflowReason_Resize
124 Position Dropdown at: 0 330 1110 480
nsComboboxControlFrame::Reflow 145   Reason: eReflowReason_Resize
125 Position Dropdown at: 0 330 1110 480
nsComboboxControlFrame::Reflow 146   Reason: eReflowReason_Resize
126 Position Dropdown at: 0 330 1110 480
Warning - table cell content max element height 480 greater than desired height
360
nsComboboxControlFrame::Reflow 147   Reason: eReflowReason_Resize
127 Position Dropdown at: 0 330 1110 480
nsComboboxControlFrame::Reflow 148   Reason: eReflowReason_Resize
128 Position Dropdown at: 0 330 1110 480
Warning - table cell content max element height 480 greater than desired height
360
nsComboboxControlFrame::Reflow 149   Reason: eReflowReason_Resize
129 Position Dropdown at: 0 330 1110 480
nsComboboxControlFrame::Reflow 150   Reason: eReflowReason_Resize
130 Position Dropdown at: 0 330 1110 480
Warning - table cell content max element height 480 greater than desired height
360
nsComboboxControlFrame::Reflow 151   Reason: eReflowReason_Resize
131 Position Dropdown at: 0 330 1110 480

Updated

19 years ago
Assignee: karnaze → troy

Comment 1

19 years ago
Troy, I believe the incremental reflow solution we talked about (involving
the ability to say that nothing changed) will fix this since the table code is
probably doing a bunch of pass 1 reflows.

Updated

19 years ago
Assignee: troy → kmcclusk

Comment 2

19 years ago
I don't want to get stuck with this bug. Assigning to Kevin first to see if he
can avoid doing a reflow in the first place. That's the real problem

A seconday issue is optimizing table incremental reflow

Comment 3

19 years ago
Kevin, if we can't avoid the incremental reflow of the combo box frame, then you
should assign the bug back to me, of course
(Reporter)

Comment 4

19 years ago
Created attachment 1358 [details]
Simplified test case (poll.html)

Updated

19 years ago
Summary: [PP] [PERF] Win32 - Drop-downlists take too long to show → [PP]Win32 - Drop-downlists take too long to show
Whiteboard: [Perf]

Updated

19 years ago
Assignee: kmcclusk → troy
After talking to Peter, there doesn't seem to be anyway that I can avoid doing
an incremental reflow. All of the gfx form elements use style rules to control
their appearance in the active state. The only way to tell if the button hasn't
really changed size is to reflow it's children. Even if I were to do something
special for the combo box button it would not solve the problem for other form
elements such as HTML4 buttons. In their case, the style rules for active can
apply both to the button and it's contents. There isn't anyway for the button to
know whether its content will change size unless the active style rule has been
applied to its children. Hopefully, the solution of returning whether the size
actually changed during incremental reflow will improve combo boxes and other
form elements performance when they are placed within nested tables.

Troy, reassigning back to you.

Troy, reassigning to you.

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11
(Reporter)

Updated

19 years ago
OS: Windows NT → All
Summary: [PP]Win32 - Drop-downlists take too long to show → Drop-down lists take too long to show
(Reporter)

Comment 6

19 years ago
Changing platform etc. to ALL. Using the 19990914xx builds on Linux and Windows
NT, performance is abysmal at (for example) my.yahoo.com. At My Yahoo!, I have
my page customized to show Flight Reservations. In this section, there are
drop-down lists of number of people, etc. On a 200 MHz Pentium running NT, it
takes 12-15 seconds to drop down those lists. A 350 MHz Pentium II running Red
Hat Linux 6 takes 10-12 seconds to drop down those lists. This is not good.

Updated

19 years ago
Target Milestone: M11 → M13

Comment 7

19 years ago
I need a real URL to test with. The simplified test case displays reasonably
quickly for me, and I don't think that's a big problem

As far as my.yahoo.com, I need something more concrete than a URL that I have to
customize to reproduce the problem

Please provide a suitable URL (or attachment) that demonstrates the problem
(Reporter)

Comment 8

19 years ago
I agree. The original test case (attachment - poll.html) is a Win32 only
problem. If you'd like to see the problem with My Yahoo!, I've created a sort-of
version of that page for internal use only at http://schist/myy - try that on
Linux and Win32; it should show the performance issue. Just click on the Total
number of travellers thingy to select a number. It takes upwards of 15 seconds
to show on a 200 MHz Pentium with MMX running NT.

Comment 9

19 years ago
Thanks for the test case. Yes, the performance is unbelievably horrible
(Reporter)

Updated

19 years ago
Whiteboard: [Perf] → [Perf][BLOCKER][BETA]

Updated

19 years ago
Assignee: troy → kmcclusk
Status: ASSIGNED → NEW

Comment 10

19 years ago
Kevin, when I look at the simplified test case above I see that there are _six_
style changed reflow commands being generated starting from when I move over the
combo box drop-down button.

The first such reflow comamnd happens when the button is entered, _before_ I
even click on the button.

I think the first order performance issue here is the fact that six reflow
commands is five more than should be generated

I'm reassigning the bug back to you. When the number of reflow commands is
reduced to something resonable (like one), if we still have a performance
problem on pages with tables then reassign the bug back
I changed the hover border width to match the default border width and that got
rid of the reflows that where happening upon entering the combo box button.Ther
e are still two reflows generated when clicking on the combo box dropdown. These
are caused by style rules which adjust the padding to make the button look
depressed. (1 reflow for down, 1 reflow for up).

Updated

19 years ago
Whiteboard: [Perf][BLOCKER][BETA] → [Perf][BLOCKER][BETA] I have a fix in my tree for combo boxes
Target Milestone: M13 → M11
I can fix the performance problem by not setting the padding on the combobox
dropdown button. I have the fix in my tree, just need permission to check it in.

The general problem is that setting padding causes a reflow. The padding is
needed to make buttons look "depressed".

Troy and Peter are working on a optimization which will allow padding to be
changed without generating a reflow if the overall dimensions of the content
area does not change.

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11 → M12

Updated

19 years ago
Assignee: kmcclusk → peterl
Status: ASSIGNED → NEW
To remove combobox reflows I changed padding settings for  the select's active
button to match non-active state. I Also changed padding+border to match between
button's with focus and active buttons drawn with focus. Added gif for active
state of combo box to indicate that it is depressed.

Still requires an optimization for collapse to prevent reflows from happening
when the combo box button is clicked on.

Peter, re-assinging to you.

Updated

19 years ago
Assignee: peterl → pierre

Comment 14

19 years ago
This is the NS_STYLE_HINT_MOVE issue.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Blocks: 16950
(Assignee)

Updated

19 years ago
Whiteboard: [Perf][BLOCKER][BETA] I have a fix in my tree for combo boxes → [dogfood]
(Assignee)

Updated

19 years ago
Priority: P3 → P2

Updated

19 years ago
Blocks: 17432

Updated

19 years ago
Blocks: 18951

Updated

19 years ago
Blocks: 20203

Updated

19 years ago
Assignee: ckritzer → pierre
QA Contact: phillip → ckritzer
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 15

19 years ago
Accepting the bug again. I guess it was a mistake from gerardok. That bug should
have never left my list.
(Assignee)

Updated

19 years ago
Target Milestone: M13 → M14

Comment 16

19 years ago
Moving [DOGFOOD] in Status Summary to dogfood in keyword field.
Keywords: dogfood
Whiteboard: [dogfood]

Comment 17

19 years ago
This works pretty good for me with 2000021509. Marking WorksForMe.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Updated

18 years ago
No longer blocks: 17432

Updated

18 years ago
No longer blocks: 18951

Updated

18 years ago
No longer blocks: 20203

Comment 18

18 years ago
Marking VERIFIED WORKSFORME on:
- LinuxRH62 2000-09-07-08-M18 Commercial
- Win98     2000-09-07-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.