Visual artifacts when painting custom component inside a Viewport

General JUCE discussion
1

Hi,

I have the following UI layout:

  1. one rather large custom Component “Box1” displayed inside a Viewport;
  2. one small custom Component “Box2”, outside the Viewport, draggable around;
  3. a main window containing everything.

Main.cpp
MainComponent.h
MainComponent.cpp

Each component has its own paint() method. For the large one (Box1) I would like to paint only the visible part by using the clipping bounds provided by the Graphics class, instead of a “raw” getLocalBounds(). E.g.:

void Box1::paint(Graphics& g)
{
    g.setColour(Colour(150, 150, 150));
    g.fillRect(g.getClipBounds());   // g.fillRect(getLocalBounds()) would paint outside the viewport
    g.setColour(Colour(200, 200, 200));
    g.drawRect(g.getClipBounds(), 1);// g.drawRect(getLocalBounds(), 1) would paint outside the viewport
}

So far so good. However, as soon as I drag Box2 over Box1, Box1 gets visually damaged by Box2. The only way to repaint it properly is to move the viewport scrollbar a bit.

So I’m asking if there is a better/proper way to smart re-paint the component inside the viewport. I’m aware of Viewport::getViewArea(): should I use it to somehow adjust the clipping bounds to my needs during Box1::paint()?

2

Not sure you’ve understood what Graphics::getClipBounds is intended for - it gives you the damaged sub-region that’s being repainted, which could be any part of the component. The best advice for a beginner is to completely ignore it… Passing it to fillRect is counter-productive, and I’ve no idea what you expected to happen by drawing a border around it, but that really doesn’t make any sense! All the graphics methods already clip to it, so you don’t need to try to help them do their job!

3

Hi jules, thank you for your feedback. As I suspected I completely misunderstood the Graphics::getClipBounds behavior :smile:

I’m asking this because I was able to trigger an assertion in juce_EdgeTable.h by painting with g.fillRect(getLocalBounds()); a very large component inside a viewport. So I thought that some smarter drawing would be required. But at this point I guess it is just wrong to have such huge components around…

4

Wow, must be pretty huge to overflow numerically!

Yeah, if you’re doing that kind of stuff then you probably do want to be smarter about it, and use smaller components or something.

1 Like