Re: Prioritizing drawing of the important stuff
Re: Prioritizing drawing of the important stuff
- Subject: Re: Prioritizing drawing of the important stuff
- From: Slipp Douglas Thompson <email@hidden>
- Date: Sat, 29 Oct 2016 06:27:45 -0500
You could just set up a simple debounce timer— reset it back to 0sec elapsed time whenever the slider is updated, and if it reaches a small delay then the HQ image is rendered (and remains on-screen until the slider is later moved and the process repeats). No need to rely on GCD or threading.
— Slipp
> On Oct 29, 2016, at 4: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