Skip to content

Cache the prepared background bitmap to avoid re-rendering on every paint - #1402

Open
zencode1 wants to merge 4 commits into
JAM-Software:masterfrom
zencode1:background-bitmap-performance
Open

zencode1 wants to merge 4 commits into
JAM-Software:masterfrom
zencode1:background-bitmap-performance

Conversation

@zencode1

@zencode1 zencode1 commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Summary

  • StaticBackground/TileBackground previously called PrepareBackGroundPicture on every paint, which allocates a new TBitmap, resizes it, and re-renders the background graphic (including a MaskBlt/transparency pass) even though the result is identical from one paint to the next.
  • This PR adds FBackgroundPrepared (bitmap + the BackgroundColor/Transparent settings it was rendered with) and a new GetBackgroundBitmap helper that only re-renders when the background color or transparency setting has changed since the last paint; otherwise it returns the cached bitmap. The cache is also invalidated whenever the background picture changes (Background.OnChange).
  • Noticeably reduces CPU/GDI cost for scrolling and repeated repaints on trees with a background image, since the expensive preparation step now runs only on actual settings changes instead of every paint.

Notes for reviewers

  • PrepareBackGroundPicture is unchanged - the existing TImage-style BackGroundImageTransparent contract (issue Background image should support transparency #662) is preserved.
  • The cached bitmap is freed and recreated (not resized in place) whenever it needs to be regenerated, so there's no risk of stale pixels bleeding through on a cache miss.
  • The final commit ("Clean up indentation") is whitespace-only and optional - feel free to skip or squash it if you'd rather keep history minimal.

Concerns

  • Since Background is a public property, and OnChange is a single public callback, if a consumer assigns Background.OnChange after construction, it replaces this handler. Any subsequent changes then leave FBackgroundPrepared.Bitmap stale, and the tree continues painting the old image. To resolve this, we would need a more robust notification mechanism. That is beyond the scope of this PR.

Test plan

  • Verified background image rendering (static and tiled modes) is visually unchanged before/after this change, including with BackGroundImageTransparent on/off and non-bitmap graphics (icon/PNG).
  • Verified switching the background image, background color, or BackGroundImageTransparent at runtime still updates the displayed background correctly.
  • Built VirtualTreesDevelopment.groupproj (Debug) - compiles clean, 0 warnings on the modified unit.

@zencode1
zencode1 force-pushed the background-bitmap-performance branch from 4009f28 to 1da02df Compare September 21, 2026 15:03
@zencode1

Copy link
Copy Markdown
Contributor Author

After making the PR, I noticed that it is possible for aBkgColor to be a system color which could leave the cached image stale after a style change. To resolve this issue, I added a call to ColorToRGB.

Additionally, I added a "Concerns" section to my description regarding a possible problem if a consumer makes use of Background.OnChange.

@Daniel-Tr
Daniel-Tr self-requested a review September 22, 2026 13:09

@Daniel-Tr Daniel-Tr left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for the concerns mentioned in the PR:

To resolve this, we would need a more robust notification mechanism. That is beyond the scope of this PR.

This is a potential breaking change (even though most likely not very likely), so I think we should address it first.

This branch has not been deployed

No deployments
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