Hi Graham,
thanks for taking the time to put this together and I am glad to hear, you
enjoyed it. Very nice graphics.
In the mean time I have also experimented with this approach, and I believe
this is the right thing to do. Also, there was some misconception on my end
of what is going on behind
OK, I needed a diversion from serious work and was intrigued to find out how
practical it is to animate many instances of an analogue meter and how far you
can go with the standard view update mechanism. Think of it as putting my money
where my mouth is. I claimed it should be possible to get sm
On Wed, 15 Jun 2011 22:47:44 +1000, Graham Cox said:
>On 15/06/2011, at 10:30 PM, Wolfgang Kundrus wrote:
>
>> We have to update a lot of small onscreen objects and performance is
>way better, when we travers them outside the Cocoa view tree. If we
>would use invalidating, we would have to go thru
On Jun 15, 2011, at 8:42 AM, Wolfgang Kundrus wrote:
> That aside, I am trying to understand, why Cocoa does not flush the
> graphics, if there has been drawn something to the window with the a method
> that works well otherwise. I understand coalescing updates and I want to
> stay away from CGCon
On 15/06/2011, at 11:42 PM, Wolfgang Kundrus wrote:
> Thanks for taking the time to respond. I am certainly not a newbie, being a
> Mac programmer since 1987 having brought three major applications with
> millions of customers to market that all run cross platform.
Cool. I wasn't calling into
Thanks for taking the time to respond. I am certainly not a newbie, being
a Mac programmer since 1987 having brought three major applications with
millions of customers to market that all run cross platform.
That aside, I am trying to understand, why Cocoa does not flush the
graphics, if there has
On 15/06/2011, at 10:30 PM, Wolfgang Kundrus wrote:
> We have to update a lot of small onscreen objects and performance is way
> better, when we travers them outside the Cocoa view tree. If we would use
> invalidating, we would have to go thru our complete view tree and check for
> overlaps wi
We have to update a lot of small onscreen objects and performance is way
better, when we travers them outside the Cocoa view tree. If we would use
invalidating, we would have to go thru our complete view tree and check for
overlaps with the update rect.
Wolfgang
This did not influence it in a pos
On 15/06/2011, at 7:16 PM, Wolfgang Kundrus wrote:
> This did not influence it in a positive way. [NSWindow display] makes it
> worth and takes down the performance of the whole application.
>
> > Is there anyway, I can inform the window that graphics need to be flushed ?
>
> Have you tried
This did not influence it in a positive way. [NSWindow display] makes it
worth and takes down the performance of the whole application.
> > Is there anyway, I can inform the window that graphics need to be flushed
> ?
>
> Have you tried [NSWindow displayIfNeeded] (or just [... display])?
>
>
___
On 15/06/2011, at 1:04 AM, Wolfgang Kundrus wrote:
> Is there anyway, I
> can inform the window that graphics need to be flushed ?
Have you tried [NSWindow displayIfNeeded] (or just [... display])?
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@list
Hi,
I have a problem with the rate at which coalesced updates refresh the
window. We draw some animations outside the drawRect method, using
lockFocus/unlockFocus, but these drawing operations are only flushed about
ones a second. The do get flushed on mouse moves though. Is there anyway, I
can in
12 matches
Mail list logo
