# CachedComponentImage invalidation logic

**URL:** <https://forum.juce.com/t/cachedcomponentimage-invalidation-logic/21768>\
**Category:** General JUCE discussion\
**Created:** [April 11, 2017, 12:30pm UTC](https://forum.juce.com/t/cachedcomponentimage-invalidation-logic/21768 "2017-04-11T12:30:23Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [April 11, 2017, 2:55pm UTC](https://forum.juce.com/t/cachedcomponentimage-invalidation-logic/21768/4 "2017-04-11T14:55:18Z")

</div>

> [@anthony-nicholls](#):
>
> if I call repaint() on Component B, Component A’s invalidate() methods will be called, why?

If the parent is buffered, then part of that image is the child component. So if the child needs repainting, of course the parent needs to invalidate its image!

Having nested, buffered, opaque components that aren’t perfectly efficiently handled could just be an edge-case that was overlooked, or where it just wasn’t worth the extra step of checking for occlusion just to handle a rare situation.

---

_[View the full topic](https://forum.juce.com/t/cachedcomponentimage-invalidation-logic/21768)._