I am developing a MacOS app with a vertically oriented ScrollView. Inside that View I use a LazyVStack. In the LazyVStack I have a column of images. I want the images to occupy as much of the LazyVStack width as possible so I created a frame for the VStack with a maxWidth: .infinity.
When the user grabs the edge of the window and drags it to reduce the window width, the Views of the window adjust themselves to fit the reduced space. This includes reducing the width of the images. I maintain a fixed aspect ratio for the images, so the height of the images is reduced too.
My problem arises when the width of the images (and height) reduces to the point where the scroll bar is no longer needed because all of the images fit within the height of the ScrollView, and the ScrollView removes the scroll bar. That triggers a redraw of the images, with a slightly bigger size because the width used by the scroll bar is now available. When the the images get bigger they don't all fit within the height of the ScrollView anymore and the scrollbar is restored. That, of course, reduces the space available for the images, so they are reduced in size again - which then triggers the ScrollView to remove the scrollbar again. The whole thing goes into a spasm of flickering images (bigger and smaller) and scrollbar (off and on) until finally I get the dreaded error message:
The window has been marked as needing another Display Window pass, but it has already had more Display Window passes than there are views in the window.
There seems to be no way to prevent this behavior by setting an option on the ScrollView. It would be great if one could indicate that the scroll bar should always remain visible, or at least that the space occupied by the scroll bar remain, even if it is just empty.
The only way I could solve this problem was to go through a somewhat involved calculation to set the image width in such a way that it still responds to window width changes (and some other size changes I allow in some of the other app's Views). This complication would not be necessary if there were better controls on the scroll bar.
Is there a reason for not providing adequate controls for the ScrollView? Its uncontrollable behavior complicates the programming.