it would be great if the ResizeableWindow class had an option in the constructor that caused the resized() method to not be called until you released the mouse when dragging the ResizableBorderComponent or ResizableCornerComponent.
Right now, every single change in pixel dimensions for the Border/CornerComponent results in setBounds() being called for the ResizeableWindow instance.
Perhaps there is a way to make the ResizableCornerComponent::mouseDrag method not call lines 72-82 in juce_ResizableCornerComponent.cpp unless a flag is set? That same flag would control if the code was actually executed inside of ResizableCornerComponent::mouseUp. Or make it draw a see-thru rectangle that shows the new bounds for what you’re resizing, but the ResizableWindow doesn’t receive a setBounds() call until ResizableCornerComponent::mouseUp is called…
There’s probably a good reason why no operating system has done it that way since Windows 95…
Definitely not something we’d have any interest in adding to juce. But you could write your own version if you really think it’s the right thing for your app. You’d need to make your own version of ResizableBorderComponent that creates a temporary floating transparent window when you drag it, so that it can be dragged beyond the bounds of the parent window, and I can imagine it’d be a pain to fix all the edge cases for it, so you’d better have a really good reason for wanting to do it that way!
I’m trying to eliminate a bunch of calls to resized() which recalculates a bunch of Path() objects. Each path object has about 150-200 elements in it. I briefly broached the subject in this thread: Path Class memory usage
Perhaps I don’t need to worry about the memory usage for these paths and the cost of recalculating them. MakeMusic’s Finale resizes their score windows this way (with the transparent window) so they don’t redraw the score until the new window size is set via the user’s MouseUp. They’re drawing a ton of font glyphs everywhere, so I can see why they wait to redraw until the user finishes changing the window size. But who knows, it might just be a relic of something they implemented in early versions from 2001 or earlier.
Thoughts on how large a path object has to become before redrawing it in a resized() causes ugly slowdowns?
No idea, it’s something you’d need to profile. But this is why there’s a Path::preallocateSpace() method. If you know you’re building a huge path, then calling it before you start may help a lot.
