Re: Cheap replacement for bezierPathWithOvalInRect fill?
Re: Cheap replacement for bezierPathWithOvalInRect fill?
- Subject: Re: Cheap replacement for bezierPathWithOvalInRect fill?
- From: John Stiles <email@hidden>
- Date: Thu, 20 Apr 2006 14:36:54 -0700
The route of absolute best performance is likely to be an NSOpenGLView.
This has its own set of issues, of course—all the rendering code you
have today for that view needs to get junked. But for blazing
performance, OpenGL can't be beat. (Until Quartz 2D Extreme, at least!)
On Apr 20, 2006, at 2:29 PM, Scott Ellsworth wrote:
On Apr 20, 2006, at 5:09 AM, Scott Thompson wrote:
On Apr 19, 2006, at 7:43 PM, Scott Ellsworth wrote:
I experimented with caching the bezier paths, and with changing
the bezier path curve control points, and neither of these turned
out to the bottleneck. My bottleneck is the fill command on the
circles.
It appears my best options are either using Quartz directly, or
creating an image and blitting that. Is there a third option I
missed, and does anyone have any strong opinions on which is
likely to be straightforward and performant? (I know, I know -
choose only one.)
(NB - I did read the docs, which is what convinced me to try
moving the control points. I also did some list archive
searches, and got inconclusive results for which would work best.)
Is there a relatively small set of colors, or is each circle it's
own color?
Small - only four just yet.
If there are a relatively small selection of colors, then you
might stuff each different colored circle into a CGLayer blitting
the CGLayers is supposed to be the most efficient way of
reproducing graphics many times on the screen..
That looks pretty interesting. I will investigate.
I tried something a bit simpler - creating a cached NSImage, then
blitting that to the screen at each update. That dropped usage
from 30% or more down to 14%, of which 9 is in the image blit, and
4 is in the fillRect that fills my view and the [[NSBezierPath
strokeRect:[self bounds]] that frames it with a border.
(More intelligence regarding what needs refresh when the data
changes would help the border draw - when the majority of the time
went into drawing the circles, it did not matter, but once the
border draw becomes important, more smarts looks like a good idea.)
Another solution, if it's possible, might be to select all the
circles of a given color, create one large path with just the
circles of that color, and draw that path all at once.
This does not work well for this case, as I have only nine circles
per view, but a few dozen views with similar structures.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden