Re: Prioritizing drawing of the important stuff

[Jonathan Taylor]

Hi everyone,

Thankyou all for your replies. Plenty of food for thought there - much 
appreciated. Looks like timers and flow control is the way forward then, if I 
want to tackle this. I just thought I'd see if there was anything built in to 
the standard UI frameworks that might be able to help, but it seems not.

To answer one of Quincey's comments:

>> The low priority thing only really runs  when *nothing* else at all is 
>> happening.
> 
> This shouldn’t be happening, on most Macs. An average desktop Mac has at 
> least 2 CPU cores (4 logical CPUs), which should allow at least 2 
> compute-bound tasks to proceed simultaneously...

The reason for this is that the coalescing, post-when-idle NSNotifications I 
was talking about were being posted to the main queue. Hence all the main queue 
time was being taken up in ultra-smooth drawing of sliders etc, since that of 
course also happens on the main queue (UI drawing...). I agree that it looks as 
if I should bite the bullet and run all this stuff multithreaded. The thing is, 
a lot of it doesn't fundamentally ~need~ to run multithreaded - one thread 
should be enough to get drawing responsiveness that I'm pretty happy with, if I 
could just find a way to control what priorities the different aspects are 
being treated with. Sounds like timers, flow control and/or multiple 
threads/queues is the way to go if I want to solve this properly.

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Prioritizing drawing of the important stuff

[Georg Seifert]

___

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

Re: Prioritizing drawing of the important stuff

[Alastair Houghton]

On 29 Oct 2016, at 10:37, Jonathan Taylor  wrote:
> 
> 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?

A couple of comments:

1. Have you checked how frequently the KVO notifications fire as you move the 
slider? If the answer is more than 60 times a second, you should probably think 
about triggering only the *first* view update from the KVO notification, with 
subsequent view updates running on a timer until the slider has stopped moving.

2. For the “slow” image, you could run it at lower priority, but as you have 
noticed that might result in starvation if there is a higher priority thread 
that is always ready to run. An alternative would be to run in a normal 
priority thread; if that uses up too much CPU (for instance), you could 
consider explicitly sleeping occasionally (with e.g. nanosleep()).  Another 
option that sometimes works well in these kinds of situations is to start a 
timer when the slider first moves, resetting it every time you get a move 
notification, and only do the expensive drawing when the timer completes; you 
can obviously adjust this policy for your specific circumstances.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

Re: Prioritizing drawing of the important stuff

[Quincey Morris]

On Oct 29, 2016, at 02:37 , Jonathan Taylor  
wrote:
> 
> The low priority thing only really runs  when *nothing* else at all is 
> happening.

This shouldn’t be happening, on most Macs. An average desktop Mac has at least 
2 CPU cores (4 logical CPUs), which should allow at least 2 compute-bound tasks 
to proceed simultaneously, provided they don’t have any accidental mutual 
dependencies, and provided the system overheads of changing the display at 60 
fps don’t amount to maxing out one of the CPUs. So you might want to spend some 
time in Instruments to get an idea of how your CPUs are getting used.

The other thing you should probably consider is what percentage of images 
you’re rendering but never pushing to the display, or rendering and pushing to 
the display too late. You might want to change to a more predictive model of 
what images to render.

You can also consider whether using a display link (CVDisplayLink) would help 
you decide what to render and when. A display link is basically a callback 
function that’s called at the display frequency. You may not want to render the 
low-res image on every display cycle, but you might be able to use the display 
link to rate-limit your calculations.

Finally, you should also pay attention to what kind of image you’re rendering 
in the background. If you’re creating a NSImage, it’s quite possible that vast 
amounts of CPU time are being spent copying the image data into a different 
pixel format and mapping colorspaces. It may be that using layer-based drawing 
works better for this sort of thing. If you really want to get into this, you 
could also investigate moving your image rendering into the GPU.

But I suggest you start with Instruments.

___

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

Re: Prioritizing drawing of the important stuff

[Alex Zavatone]

Using this as a mental exercise, why not make a system that tracks the time it 
takes to render each image as each one draws and then schedule each item's 
render interval based on how much time each one needs to render?

Just to throw caution to the wind, for "teh luls" and just to see what happens, 
set an "interval upon which to render" for each image based on the amount of it 
takes to complete its own render, wire up your "renderMeCommaStupid" method to 
itself then hit the on switch and let her rip.

Have each image responsible for its own rendering.  Then test the limits to 
this madness by allocating a metric crapload of  images until the performance 
starts to suck.  As a "cheesy and simple stopgap because we don't know any 
better", have one or two properties in your image renderer manager that are 
your control limiters, like min time required before another render or your min 
time required for an update OR desired max updates per global time unit (max 
FPS).

Now, if that completely sucks things that do not need to be sucked, you can 
just go mad and have each item that is supposed to be available for its own 
rendering into a two stage fifo queue (as opposed to a priority based queue).

The first queue would be "things that need to render" and it would have a max 
amount of "things that can be in the queue".  The second queue would be "things 
which I am actively going to let render", which contain the reference back to 
the item that has politely asked to render.  

When the thing in the second queue actually gets to the point of "whoa, you 
actually want to let me render now?"  What it does is…

actually check "the global overlord setting" for max FPS or whatever you 
called it - if it passes, proceed to the next step, otherwise return
ask the object manager, "hey, if take the time now and the object's last 
time it rendered (another property on the object, the timeOfLastRender) is it 
=> the next time it can be updated
if these conditions are not passed, just return
if these conditions are passed, then tell the object, 
"whatAreYouWaitingForQuestionMarkRenderYourself" and this gets the object to 
render and store its timeOfLastRender.

While the whatAreYouWaitingForQuestionMarkRenderYourself method is called, it 
tracks the time to render in a "howLongItFreakingTookToDrawMe" property, which 
is the essential governor that each object has which allows the frequency of 
its updates.  A self controlling/self regulating system, if you will.  
Scienticificans call this a homeostatic system, but hopefully this one is 
better than our US housing loan self regulation and with less dire consequences 
if it screws up.  

Hopefully.  

And if this causes a flicker, or if you need a cleaner display, then don't have 
each item render itself, but have them flagged To render, and then have the 
overall manager render all of the items into an offscreen bitmap, lock the 
current representation of the screen, switch out the image behind your current 
scene, remove the lock, update the screen, then place an exact copy of the 
thing you just drew on top of that, and use the image behind as the one to swap 
out at the next render interval.  But you don't have to.

Now, how do I know this is not a horribly terrible idea?

Back last century when there was this multimedia tool and engine called 
Director, and it's "bitmap rendering multimedia engine in a browser" called 
Shockwave, we had the what you could consider a scripting language based (OO 
and SmallTalk with HyperTalk or Lua like syntax) single threaded version of we 
could consider Cocoa is, but without anything past a rudimentary set of a UI 
framework.

So I built it.  

Part of this was writing something to get async animations on a single threaded 
system that wouldn't run wild and take the system down if the animation system 
required too much cycles, so I made it self regulating and wrote primitive 
pseudo threads,  The goal was that, "if something's animating, never lock the 
user out of interacting with the system".  And to test that it actually worked, 
I broke it.  By overloading the system, we find its failure point.  So, I 
overloaded the system by animating hundreds to thousands of objects and i ran 
out of memory before it started sucking. Noting that this was at a time when 
Macs had processors called G3, their clock speed was between 233 and 700 MHz 
and if you were lucky, your system had a GB of RAM, if something like worked 
well then, it certainly will work well now.
  
Plus, it's fun.

Go crazy.  If you have time, give it a shot. 

Alex Zavatone

On Oct 29, 2016, at 4:37 AM, Jonathan Taylor 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 

Re: Prioritizing drawing of the important stuff

[Peter Tomaselli]

Not at all my area of expertise, but I was going to suggest some sort of 
debounce-style approach as well. That is, there is somewhere an event stream 
that is firing off “please redraw everything” events (I think you said this was 
a KVO subscription) at some potentially excessive rate, right?

So I would debounce that twice into two new streams: once to create a “redraw 
the lightweight stuff” event stream that’s capped at 30 Hz (or whatever), and a 
second time to create a separate “redraw the slow stuff” event stream at 5 Hz 
(or whatever).

So, nothing to do with monkeying about with how the system prioritizes drawing 
internally, instead “sanitizing” your event stream up front based on what you 
know about the drawing performance characteristics downstream.

Apologies if this is way off base, I have very little experience with Cocoa 
drawing itself. :)

Peter

> On Oct 29, 2016, at 7:40 AM, Jonathan Taylor  
> wrote:
> 
> The point, though, is that the slider will happily update pretty much as as 
> often as the CPU allows. The issue is how to control what the OS considers to 
> be "smooth enough" slider updates - there's a point at which I'd much rather 
> have it "only" update the slider and the quick-to-draw image 10 times/sec, 
> and have a bit of time spare to do the low-priority drawing, rather than 
> updating the slider and easy image 60 times/sec.
> 
>> On 29 Oct 2016, at 12:27, Slipp Douglas Thompson 
>>  wrote:
>> 
>> 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

___

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

Re: Prioritizing drawing of the important stuff

[Jonathan Taylor]

The point, though, is that the slider will happily update pretty much as as 
often as the CPU allows. The issue is how to control what the OS considers to 
be "smooth enough" slider updates - there's a point at which I'd much rather 
have it "only" update the slider and the quick-to-draw image 10 times/sec, and 
have a bit of time spare to do the low-priority drawing, rather than updating 
the slider and easy image 60 times/sec.

On 29 Oct 2016, at 12:27, Slipp Douglas Thompson  
wrote:

> 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  
>> 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/apple%2Bcocoa-dev%40slippyd.com
>> 
>> This email sent to apple+cocoa-...@slippyd.com
> 


___

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

Re: Prioritizing drawing of the important stuff

[Slipp Douglas Thompson]

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  
> 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/apple%2Bcocoa-dev%40slippyd.com
> 
> This email sent to apple+cocoa-...@slippyd.com


___

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

Re: Prioritizing drawing of the important stuff

[Jonathan Taylor]

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  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  
>> 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

Re: Prioritizing drawing of the important stuff

[Jeff Szuhay]

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  
> 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

Prioritizing drawing of the important stuff

[Jonathan Taylor]

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com