Re: Views, scrolling, zoom and detail
Re: Views, scrolling, zoom and detail
- Subject: Re: Views, scrolling, zoom and detail
- From: Brent Gulanowski <email@hidden>
- Date: Wed, 12 May 2004 10:45:49 -0400
I myself would do all such drawing with OpenGL. It would do what you
want without breaking a sweat. A whole new API to learn, unfortunately.
While Quartz Extreme accelerates many Quartz routines through OpenGL,
I've not heard any evidence that it accelerates NSBezierPath. I don't
think Quartz Extreme is that fine grained. It doesn't do map general
point-based geometry primitives, only textured rectangles.
In OpenGL you could use glBegin( GL_LINE_STRIP ) to connect your sample
points, specified with glVertex2d(). Even faster, use glDrawArrays(
GL_LINE_STRIP, GLint first, GLsizei count ) with an array of vertices
(set up before hand, along with colour settings, yada yada). But then
you need to set up a context and all that other junk. If you can afford
the time, it might be worth looking into just to know.
On May 11, 2004, at 4:51 PM, Hamish Allan wrote:
>
Many thanks to Brent and Andreas, my first Cocoa app is coming along
>
nicely. I'm now starting to show time-domain audio data in a custom
>
view:
>
>
http://www.synathome.pwp.blueyonder.co.uk/zoomedout.png
>
>
I have a horizontal slider for zoom. I want it so that when the slider
>
is all the way to the left, the entire sample is visible in the
>
window, and when it is all the way to the right, the data is maximally
>
zoomed (i.e., one pixel wide equals one sample wide). The custom view
>
is contained within a scroll view with a horizontal scrollbar.
>
>
What you see in the screenshot above is actually a filled
>
NSBezierPath, composed of one path for values below zero, reversed and
>
appended to another path for values above zero. It's a crude
>
approximation to the amplitude envelope, and of course, if I'd taken a
>
value from every sample, it would be unworkably slow, so for this
>
fifteen second piece I've taken the average of every 100 samples,
>
which is still slow, but just about workable. You can see the zoom
>
slider in effect here:
>
>
http://www.synathome.pwp.blueyonder.co.uk/zoomedin.png
>
>
Of course, I want greater resolution than you see in that picture, and
>
the way the slider is designed, when it's all the way to the right
>
there should still really be a datapoint for every pixel. But it's not
>
feasible to use an NSBezierRect that way, and less crude approximation
>
would use even more pixels.
>
>
So I'm wondering if anyone on the list has any ideas about the best
>
way to go about this? I like the idea of "one method to draw them all"
>
but I don't know whether it's still feasible. Should I take my custom
>
view out of its scrollview and replace the latter with a scrollbar?
>
(Interface Builder doesn't seem to want me to use scrollbars this
>
way!) Should I keep the view in its scrollpane, and have its drawRect
>
method query the scrollbar and draw whatever is "onscreen"? Or does
>
anyone have any alternative suggestions?
>
>
Thanks again,
>
Hamish
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
>
>
--
Brent Gulanowski email@hidden
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.