perf: cache the entry tree directory icon to eliminate severe repaint lag on Windows - #328
Open
vengefulcrop wants to merge 1 commit into
Open
Conversation
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%.
Owner
|
Thank you for this, didn't think it was platform specific |
Owner
|
I'm on vacation but will merge as soon as I can |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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%.