> > We have no way of benchmarking wikipedia or any real site because of font > collection loading, which we do during style recalc. I don't know where the > other browsers do it, but because we do it during style recalc, it kills > our numbers.
What exactly do you mean by "font collection loading"? If you ask the right questions I can explain how it works in Gecko :-). Display list construction will go down massively once we only do the > visible region + a little overflow. That will make display list > construction basically not show up in the profile. It's super cheap in > Gecko, too. It's just repainting lots of tiles without DLBI that leads to > poor performance. > Much as I'd like this to be true, it's not always true. There are pathological benchmarks like "IE Maze Solver" and less pathological ones involving SVG where a very large number of DOM nodes are visible on the screen, which causes display list construction and DLBI to become a bottleneck. It would be very desirable to have a design where the work you do to get a change in the layout tree onto the screen is upper-bounded by the size of the tree change, as well as upper-bounded by what's visible (or potentially visible when you're prerendering for animations or async panning), and the cost of invalidation and painting is tightly related to what's actually changed visually. Unfortunately I don't know what that design should be... Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
