Actually, there is. This sounds a lot like the resize logic built into the
framework.
In Apple’s “View Programming Guide” there is a section dedicated to “Drawing
During Live Window Resizing”
You already have the fast and slow methods for drawing so you can use them if
you pay attention to
-(BOOL) inLiveResize
Also, you can override viewWillStartLiveResize: and viewDidEndLiveResize:
methods on your NSView.
There is also a demo app that uses bindings to change the window shape and
transparency based on its size that might be helpful.
So, I think I am saying this problem is not new and has been addressed in
several different ways in the NSView class.
> On Oct 29, 2016, at 2:37 AM, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk>
> wrote:
>
> Hi all,
>
> This is a bit of a general question, but hopefully people may have some
> suggestions. I've got some drawing code that synthesizes an image in a
> window, which will change in response to sliders (e.g. changing the camera
> perspective). My problem is how to make it so that the redrawing of the image
> is as responsive as possible as the slider moves.
>
> At the moment I just respond to KVO notifications from the slider by
> redrawing. This works fairly well. However, after further development work my
> program is now a bit more complicated. Effectively, I have two images, one of
> which is expensive to draw and one less so. What I would like is to have the
> quick-to-draw one update fairly often, and the more expensive one at lower
> priority. Does anyone have any suggestions about how to achieve this?
>
> Ideally, I would like the quick image to continue to update responsively as
> the slider moves. I am less bothered about how responsive the slow image is.
> One way I could do this is to treat it as low priority, either though a low
> priority GCD thread or through coalescing post-when-idle NSNotifications. My
> experiments so far, though, suggest that this is a rather binary thing. The
> low priority thing only really runs when *nothing* else at all is happening.
> This can lead to a scenario where (as far as I can tell via Instruments) the
> OS is spending every moment of idle time redrawing a moving slider at some
> outrageous frequency, making it look ultra-smooth, but not dedicating *any*
> time at all to doing my low-priority drawing.
>
> So, I think this basically boils down to a question of load balancing. Is
> there a good way to balance the time my code spends on different drawing
> activities, making sure all do happen to some extent, but some more often
> than others? Importantly (and most challengingly I think) this includes UI
> drawing activities that the OS undertakes on my behalf (which I have less
> control over).
>
> I fear there is no easy solution to this, but if anyone has any suggestions
> for things I should look at, that would be really helpful.
>
> Cheers
> Jonny.
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jeff%40szuhay.org
>
> This email sent to j...@szuhay.org
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
