https://bugs.freedesktop.org/show_bug.cgi?id=72125
--- Comment #3 from Noel Grandin <[email protected]> --- I've done some basic analysis of this, but I find KCacheGrind hard to follow, so take this with a pinch of salt: My preliminary conclusion is that SvTreeListBox is simply not designed for this number of elements. It appears to be doing a calculation of item height for every single item inserted, which is generating a ton of calls down into the text layout subsystem, which is adding up to a lot of time. A stripped down stack trace looks like: SvxJavaOptionsPage::ExpertConfigHdl_Impl ->CuiAboutConfigTabPage::Reset ->CuiAboutConfigTabPage::FillItems ->CuiAboutConfigTabPage::InsertEntry ->SvHeaderTabListBox::Insert ->SvTreeListBox::Insert ->SvListView::ModelNotification ->SvTreeListBox::InitViewData ->SvLBoxString::InitViewData ->OutputDevice::GetTextWidth Other ListBox implementations handle this one of two ways: (a) the client code explicitly specify the row height, and the ListBox just uses that number, not calling any text layout (b) the ListBox assumes that all rows are the same height and only calls layout for the first row. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
