Re: My god, it is so pleasant with the animations disabled on Sierra.
On Oct 27, 2016, at 4:56 PM, Rich Siegel wrote: > System Preferences => Accessibility => Display => "Reduce Motion" On Oct 27, 2016, at 6:29 PM, Alex Zavatone wrote: > Sierra, System Preferneces > Accessibility (because not wanting excess > animation is a disability, not a general preference or appearance option). > Then click on Display and look at the check box in the top right that says > Reduce Motion. Ah -- thanks, Rich and Alex. Very nice indeed. --Andy ___ 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
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
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
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
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
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
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
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
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
