The track sizing algorithm processes a list of items sorted by increasing span in order to size content sized columns. Our implementation instead processes content sized columns, meaning that an item spanning multiple content sized columns will be processed many times. Apart from that we're doing extra sorts and hast table lookups because we're reseting the list of items after processing each track.
(In reply to comment #0) > The track sizing algorithm processes a list of items sorted by increasing > span in order to size content sized columns. Our implementation instead > processes content sized columns, meaning that an item spanning multiple > content sized columns will be processed many times. > > Apart from that we're doing extra sorts and hast table lookups because we're > reseting the list of items after processing each track. Actually this was already implemented in bug 135701 but it has 2 important bugs: 1- the hash table is reset after processing each track, that means that is actually doing nothing (there are no duplicates inside the same track). 2- we're only sorting the items inside each track, we have to sort them all (all the items in the grid spanning through content sized columns).
Created attachment 244892 [details] Patch
Created attachment 244893 [details] Patch Removed a change in TestExpectations already included in master
Comment on attachment 244893 [details] Patch r=me
Committed r178893: <http://trac.webkit.org/changeset/178893>