12227 - Drop-down lists take too long to show

Status: VERIFIED WORKSFORME

(Core :: Layout: Form Controls, defect, P2)

Description

[cpratt]

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

Comment 1

[karnaze (gone)]

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.

Comment 2

[troy]

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

[troy]

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

Comment 4

[cpratt]

Attachment: Simplified test case (poll.html)

Comment 5

[Kevin McCluskey (gone)]

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.

Comment 6

[cpratt]

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.

Comment 7

[troy]

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

Comment 8

[cpratt]

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

[troy]

Thanks for the test case. Yes, the performance is unbelievably horrible

Comment 10

[troy]

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

Comment 11

[Kevin McCluskey (gone)]

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).

Comment 12

[Kevin McCluskey (gone)]

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.

Comment 13

[Kevin McCluskey (gone)]

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.

Comment 14

[Peter Linss]

This is the NS_STYLE_HINT_MOVE issue.

Comment 15

[Pierre Saslawsky]

Accepting the bug again. I guess it was a mistake from gerardok. That bug should
have never left my list.

Comment 16

[leger]

Moving [DOGFOOD] in Status Summary to dogfood in keyword field.

Comment 17

[leger]

This works pretty good for me with 2000021509. Marking WorksForMe.

Comment 18

[ckritzer (gone)]

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