Skip to content

perf: cache the entry tree directory icon to eliminate severe repaint lag on Windows - #328

Open
vengefulcrop wants to merge 1 commit into
craftablescience:mainfrom
vengefulcrop:fix/cache-directory-icon
Open

perf: cache the entry tree directory icon to eliminate severe repaint lag on Windows#328
vengefulcrop wants to merge 1 commit into
craftablescience:mainfrom
vengefulcrop:fix/cache-directory-icon

Conversation

@vengefulcrop

Copy link
Copy Markdown

Cache the icon the same way the extension icons are cached, and clear both caches when the style changes so they do not go stale. The caching itself is platform independent, but the problem it solves was only measured on Windows (Qt 6.8.3, Windows 10); other platforms may or may not have a cheap standardIcon(SP_DirIcon).

EntryTreeModel::data() returned QApplication::style()->standardIcon(SP_DirIcon) for every directory row without memoizing it, while the file icons directly below it are cached. Qt asks the model for the decoration of each visible row on every repaint, so each repaint re-extracted the platform folder icon once per visible directory.

On Windows that lookup goes out to the shell and measures about 4.3 ms per call here, on every style. With a viewport holding a few dozen rows that is well over 100 ms of icon extraction per repaint, so anything that repaints the tree - scrolling, dragging the splitter, resizing the window - stalls. A CPU sampling trace over a large archive showed that roughly a fifth of all samples sit in user32!ConvertPNGToDIBIcon, WindowsCodecs PNG inflate and the kernel alpha blit (win32kfull!ProcessAlphaBitmap, vAlphaPerPixelOnly), while Qt's own painting accounts for about 2%.

Cache the icon the same way the extension icons are cached, and clear both
caches when the style changes so they do not go stale. The caching itself is
platform independent, but the problem it solves was only measured on Windows
(Qt 6.8.3, Windows 10); other platforms may or may not have a cheap
standardIcon(SP_DirIcon).

EntryTreeModel::data() returned QApplication::style()->standardIcon(SP_DirIcon)
for every directory row without memoizing it, while the file icons directly
below it are cached. Qt asks the model for the decoration of each visible row
on every repaint, so each repaint re-extracted the platform folder icon once
per visible directory.

On Windows that lookup goes out to the shell and measures about 4.3 ms per
call here, on every style. With a viewport holding a few dozen rows that is
well over 100 ms of icon extraction per repaint, so anything that repaints the
tree - scrolling, dragging the splitter, resizing the window - stalls. A CPU
sampling trace over a large archive showed that roughly a fifth of all samples
sit in user32!ConvertPNGToDIBIcon, WindowsCodecs PNG inflate and the kernel
alpha blit (win32kfull!ProcessAlphaBitmap, vAlphaPerPixelOnly), while Qt's own
painting accounts for about 2%.
@craftablescience

Copy link
Copy Markdown
Owner

Thank you for this, didn't think it was platform specific

@craftablescience

Copy link
Copy Markdown
Owner

I'm on vacation but will merge as soon as I can

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants