-
Bug
-
Resolution: Fixed
-
Major
-
8.5.0, 8.6.0.1
-
Security Level: Jean
-
chrome is affected mostidentified-slow-styles.css
also FF shows noticable slowdown
-
None
Steps to Reproduce
run the attached example measure-onresponse.zul
scroll down to trigger new rows to be rendered
observe the browsers console
Current Result
chrome breeze:
(index):881 zAu._onResponseReady: 0.283935546875ms (index):881 zAu._onResponseReady: 0.036865234375ms (index):881 zAu._onResponseReady: 0.02392578125ms (index):881 zAu._onResponseReady: 77.556884765625ms (that's the render time)
chrome iceblue_c:
(index):881 zAu._onResponseReady: 0.261962890625ms (index):881 zAu._onResponseReady: 0.02099609375ms (index):881 zAu._onResponseReady: 0.017822265625ms (index):881 zAu._onResponseReady: 574.68896484375ms
when using "iceblue_c" chrome takes ~700% time to render the new rows
Expected Result
equal or marginally different render time
Debug Info
looking into the performance profiler, shows most of the time is spent during "Recalculate Styles" indicating a CSS problem
Root Cause
certain combinations wildcard CSS selectors negatively affect the CSS performance
e.g.:
just adding those 2 empty style rules to the breeze theme, causes a similar performance drain:
.z-combobox-input[readonly]+* { } .z-combobox-disabled>*:hover+* { }
replacing the wildcards with specifc selectors helps (not sure if a is the correct element, the implementor needs to check carefully)
.z-combobox-input[readonly]+a { } .z-combobox-disabled>*:hover+a { }
the attachment contains the iceblue_c zk.wcs with the problematic 9 rules commented out
commenting in a single of them doesn't make it slow, only certain combinations of at least 2 of these rules cause the slowdown
Workaround
- relates to
-
ZK-4153 additional slow hover styles in bigger listboxes (IE11)
- Closed