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 t
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
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 ca
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.
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 t
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
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 happen
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 t
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
