Hi Jeff, Thanks for your reply. Unless I am misunderstanding you, though, I think we are talking about two slightly different things? It seems that what you are referring to is useful in the case where there is a "low quality" and "high quality" method for redrawing the *same* image. In that case, inLiveResize would be useful for knowing which of the two to use. In my case, though, I have two separate images. In fact, one is an xy cross section through a 3D dataset, and one is a 3D rendering (which clearly takes longer to compute). It makes sense for the xy cross section redraw to be more responsive, since it is cheaper to draw, but I don't want the 3D rendering to be neglected entirely.
Is there a way that what you describe can help there, or are we talking about two slightly different things here? Cheers Jonny. On 29 Oct 2016, at 11:24, Jeff Szuhay <j...@szuhay.org> wrote: > 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
