Re: Transitioning from QD to Quartz
Re: Transitioning from QD to Quartz
- Subject: Re: Transitioning from QD to Quartz
- From: Kurt Bigler <email@hidden>
- Date: Sun, 21 Nov 2004 16:52:49 -0800
on 11/21/04 12:49 PM, R. Scott Thompson <email@hidden> wrote:
>>> Tiger does contain a routine that will take the current drawing
>>> settings and replace the current path with a path that outlines the
>>> area that will be drawn when that path is stroked. You could use
>>> that routine and then use CGContextGetPathBoundingBox.
>>
>> Hmm, that seems heavyweight. I'd prefer an mathematical solution. I'd
>> prefer an API that basically goes through the steps of rasterization
>> to figure out the bounds that fits the marked area. That's what our
>> pre-Quartz code did.
>
> You don' thave to go through that routine unless you wanted a really
> super accurate bounding box.
>
> FreeHand (professional vector illustration program an all that) had
> really good results that came from simply calculate bounding box around
> the bezier control polygon, Outsetting that by the current miter limit
> or half the maximum stroke width (whichever was larger), and then
> outsetting the resulting rectangle by a fixed slop margin just for good
> measure. Such crude calculations meant that, in unusual circumstances,
> you might draw a bit more than was strictly necessary... but in
> practice the amount of time you spent in extra drawing was more than
> made up for by having a faster, less accurate, mechanism for
> calculating a bounding box.
Yikes, I tried that approach first in our "pre-quartz" bezier code (the only
code we have) and it broke so many ways that it was not usable at all. I'd
say it is not usable if the user has the ability to adjust the control
points, and also needs to be able to see the entire curve. A slop factor
doesn't anticipate anything useful about what is a "reasonable" amount of
bowing of a curve beyond the control points. Anything might be reasonable
and the user needs to be able to see the resulting curve on the screen
(unclipped). Also pixel-based rendering operations (e.g. for bitmap export)
need to have the correct bounds for the area being drawn to, else the
exported figure gets truncated.
So to me its not a matter of "super accurate". There is no functional
alternative. If there were something "a little less accurate" it would be
fine, but there is no upperbounds on the inaccuracy of an approach that
doesn't actually do some internal rendering.
-Kurt
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden