>
>>> So is there a convenient way to throttle drawing to the monitor's refresh
>>> rate or does this have to be done the hard way by querying the monitor's
>>> refresh rate and then setting up a timer which draws in exactly those
>>> refresh intervals or how should this be done?
>
>>> Note th
> On Oct 23, 2020, at 8:54 AM, Andreas Falkenhahn
> wrote:
>
> Thanks, but once again, I still need a throttle because I obviously don't
> want to call -setNeedsDisplay as often as the CPU permits, thereby causing
> 100% CPU load. I still need some timer mechanism that only calls
> -setNeeds
Erm, but I obviously need to update the screen more often than every second. I
don't understand why I should be using an update time of 1 second. I obviously
need to call "setNeedsDisplay" more often than that...
On 23.10.2020 at 18:09 Alex Zavatone wrote:
> Naaah, it’s not that. The OSes draw
Just try the simple code I supplied with a 1, 2, second update time. If you
find that it doesn’t work, it’s 5 minutes spent. If you find that it does,
just figure out the update time that you want. 1/2 a second? 1/10 of a second?
The other thing you can have is a “hasTheDataChanged” setting
Naaah, it’s not that. The OSes draw code already handles that at a much lower
level. You’re just creating what is a maximum update throttle. You’re not
blitting pixels in a video card driver.
You can try my simple approach and just declare the next update time to be the
current time + 1 seco
Thanks, but once again, I still need a throttle because I obviously don't want
to call -setNeedsDisplay as often as the CPU permits, thereby causing 100% CPU
load. I still need some timer mechanism that only calls -setNeedsDisplay every
once in a while. So should I setup a timer based on the mon
The problem with that approach is that I'd need to find out the monitor's
refresh rate in order to calculate "nextUpdateTime" and I'm not sure if I can
get this information from all monitors reliably.
On 19.10.2020 at 00:09 Alex Zavatone wrote:
> It shouldn’t be too hard to roll your own simply
It shouldn’t be too hard to roll your own simply based on milliseconds of a
timer.
Even a simple
if (myMilliseconds > nextUpdateTime) {
[updateObject doThatUpdate];
nextUpdateTime = myMilliseconds + msThrottle;
}
lets you get a basic throttle.
Cheers,
Alex Zavatone
> On Oct
Not quite. AppKit throttle view refresh to 60fps but it certainly won't
throttle code that changes the gfx more often than that, i.e. something like
this
for(;;) view.layer.contents = (id) getNextFrame();
will hog the CPU. So I need some external timing mechanism to set
layer.contents not
CADisplayLink
Mike.
Sent from my iPhone
> On 15 Oct 2020, at 20:13, Andreas Falkenhahn via Cocoa-dev
> wrote:
>
> I'm drawing inside an NSView by simply setting its layer's contents to a
> CGImage which is updated for every frame, e.g. something like this:
>
>dp = CGDataProviderCreateW
I'm drawing inside an NSView by simply setting its layer's contents to a
CGImage which is updated for every frame, e.g. something like this:
dp = CGDataProviderCreateWithData(NULL, frameBuf, frameBufSize, NULL);
im = CGImageCreate(frameWidth, frameHeight, 8, 32, frameStride,
theC
11 matches
Mail list logo
