Re: Prioritizing drawing of the important stuff
Re: Prioritizing drawing of the important stuff
- Subject: Re: Prioritizing drawing of the important stuff
- From: Jonathan Taylor <email@hidden>
- Date: Sat, 29 Oct 2016 11:42:12 +0100
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 <email@hidden> 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 <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden