Is viewport still ideal for very large components?

[DrTarantism]

I have previously programmed using Windows Forms, in C#, and noticed that rendering large bitmaps (for displaying my wave forms) could be a disaster, depending on the length of the audio. The application would immediately crash (stating that there was not enough memory) if the audio was lengthy. Of course JUCE is much better than Windows Forms, but I am just wondering if I might still run into issues with the length of the audio, and subsequently the size of the viewport components.
At present, I am not using a Viewport at all. I have created a scroll bar, and re-render a section of the wave every time the user moves the scroll bar. However, this is causing problems because have components in the foreground, on top of the waveform and these need to move as the wave form is scrolled. Quick scrolling creates a temporary jittery glitch around the transparencies of those foreground components. So I figure, scrolling a viewport might be a solution, if there are no major drawbacks.
Any thoughts?

[jonathonracz]

Check out the AudioThumbnail class, which is designed especially for this situation. It does nifty stuff in the background to reduce draw time/memory usage for audio waveforms.

[DrTarantism]

Thanks I’m having a look right now. It looks useful, but I still am interested in the general question of whether viewports are less ideal for large components. I do have one other GUI element that displays data that is somewhat of a hybrid between a waveform and a graph. The data is not actually audio, but the data might be of considerable length. Therefore, I will at some point need to create something more custom.

[jules]

A Viewport is fine for large components as long as they’re smart enough to draw themselves efficiently - i.e. not to waste time drawing all the areas of themselves which are occluded.

Of course it also depends how big they are - coordinates are 32-bit ints, so if your component is super-large then things will start to overflow.

[DrTarantism]

Cool thanks Jules.
But if I only draw areas that are presently visible, isn’t there a risk that the user scrolls the component before it has any visuals? Like, if they scroll very quickly, I imagine the whole viewable area might be blank for fraction of a second.

[jules]

No, that’s not how components work. Everything gets drawn synchronously.

[benkuper]

Thanks for that, i’ll try that, i guess it means passing the bounds of each parents to its children so they can compute their local bounds depending on the viewport.

[jules]

@benkuper

So is there a component method i didn’t find that is able to check if it’s outside of multi-level parent bounds ?

No, nothing specifically for that. What you’d want to do is use getLocalArea() to convert the child’s bounds into the coordinate-space of the viewport, and see whether it’s off the side or not. (If there was a method to do what you need, that’s probably what it’d do internally)

[benkuper]

[anwsering a little late, but better than never ]

Thanks for the tip. I guess this would be a very good improvement to the viewport code to have an option to auto switch visible components depending on whether they actually are visible, this would be a good automatic performance gain, and people wouldn’t risk doing it wrong.

[daniel]

I think that is actually what happens. If a Viewport needs repaint, it does so supplying the visible area as dirty. Any subcomponent, that is not in this area will not paint. If all is one component, or they are transparent, this can still cascade.
In that case the clipping the Graphics happens, which helps a bit. But it cannot skip half paint calls.

That means for the user, rather call repaint() on the viewport instead of the viewed component.

[benkuper]

Are you sure about that ? Right now I have a my own way of checking if items are inside or outside the viewport to be sure that they’re not redrawn. Also this applies to resized() but I guess this is not exactly the same.
Anyway I remember having a if(isShowing()) returning always true if I didn’t handle myself changing the visibility flag of a component inside a viewport when it goes in and out of the viewing area.

[daniel]

I haven’t tested it, that’s why I started my sentence with “I think…”

This part in Component should make sure of not painting children outside the clip region:

WeAreROLI/JUCE/blob/develop/modules/juce_gui_basics/components/juce_Component.cpp#L1921

The remaining uncertainty is, if Viewport sets the clip region properly… I haven’t double checked that.

[benkuper]

Thanks for clearing that out

[daniel]

When you test this, let us know, I am curious as well, but I am in the middle of something, so I can’t test myself right now…

[fravezAt]

@daniel

eds repaint, it does so supplying the visible area as dirty. Any subcomponent, that is not in this area will not paint. If all is one component, or they are transparent, this can still cascade.
In that case the clipping the Graphics happens, which helps a bit. But it cannot skip half paint calls.

That means for the user, rather call repaint() o

Is a similar behaviour applied to subcomponent’s focus as well? Currently when browsing between the subcomponents of a component owned by a Viewport with VoiceOver turned on I am able to access the subcomponents that are hidden by the ViewPort. Is there a quick way to set a subcomponent to a not-accessible state when not present in the visible area?