On Feb 15, 2008, at 3:27 PM, Ricky Sharp wrote:
And this is why I'm really hoping they address the bug I filed (to
revert drawing behavior to what it was, yet add an API that
developers can choose to set if they want to in order to get new
behavior). Nobody should have to attempt to fudge offsets based
upon an OS release.
Also, for those customers with older versions of your app that
choose to remain on those versions (e.g. maybe they don't want to go
with a paid upgrade), they'll end up getting different output when
moving to 10.5.2 and beyond. That's unacceptable IMO.
Well, I filed a DTS incident about this and would like to share the
results. According to the reply, it's unlikely that the behavior will
be reverted back.
The good news is that there's a workaround. The bad news is that the
workaround doesn't work in all cases. (I've already updated the bug I
filed with all my research notes below).
Here's the explanation I received:
"The reason that the shadows are different in 10.5.2 is that there was
a change in an underlying math library. Prior to 10.5.2 when
calculating the shadows the values passed in were truncated(via the
floor function). Now(in 10.5.2) they are rounded. So one possible
workaround is to subtract 0.5(or add 0.5 if the value was negative)
from your offsets and blur values. This should give you similar
results on both 10.4 and 10.5.2."
In my particular case, all but two shadow instances in my app use
offsets of (2, -2) and blur values of 2. The two special cases are
{ (4, -4), 4 } and { (5, -5), 7 }.
My shadows are mostly stored in nibs (custom IB plug-ins allow editing
of all their attributes). Other shadows are dynamically built at run-
time. In _all_ cases, |xOffset| = |yOffset|
Also, when rendering text with shadows, I found that shadows can be
clipped if drawing into the bounds as returned by NSAttributedString's
measuring APIs. I thus modify that size by the sum of an offset and
blur radius. Because of this, I couldn't apply the 0.5 modifications
to my stored objects as I would end up with different sized rects
depending on OS. And, that would cause my UI elements to now have
different origins. Instead, I strategically placed a "normalize" API
I came up with that would only modify the shadow after I had the
original offset values for my computations of the drawing dest rect.
Anyhow, I then ran the "pre" and "post" workaround apps (on the same
hardware) under both Mac OS X 10.4.11 and 10.5.2. A total of 18
screen-shots were taken for each combo for a total of 72 images. I
then computed various differences in Photoshop CS 3. In all cases,
images were converted to the working color space of Apple RGB.
Thankfully, all but my special case shadows showed _no_ differences
between pre and post when running on 10.4.11 (i.e. users of that OS
would see no difference with their current app and the app containing
the workaround).
Also, no difference*** between the pre/post 10.4.11 and post 10.5.2.
Meaning that users of 10.5.2 + will now get the original rendering
behavior that they had prior to that update.
*** No difference in shadows. But, there were differences that showed
up due to the slightly different rendering of Lucida Grande Bold
10pt. Under Leopard, they render just a hair taller than under Tiger.
For the two custom shadows, they were only off by 1 extra pixel in
both directions. And, since the shadow was quite large, the extra
pixel shift ended up being very very subtle.
I then spent a small amount of time with another test nib. There, I
created a matrix of 100 of my "static text" objects in a grid of 10 x
10. Moving across, shadow offsets were set to (n, -n) where n in
[0..9]. Moving down, shadow blur values were set to n where n in [0..9]
In comparing pre and post workaround on only 10.5.2, it revealed that
the 0.5 workaround given by DTS will _only_ work the following shadows:
xOffset and yOffset in {0,1,2,3,6,7,8}
blurRadius {0..9}
I then modified the workaround to remove the 0.5 modification to blur
radius and witnessed the exact same results. However, I did not run
this on 10.4.11, so don't know if modifying the blur radius would be
necessary there.
For a final test, I applied an 0.9 modification to both offset
values. This "fixed" a few of the bad offsets (e.g. 4) but it had
it's own issues. The following shows what offset values now work with
this offset modifier:
xOffset and yOffset in {0,1,2,3,4,5,6,8}
blurRadius {0..9}
But again, the 0.9 mod was _not_ tested on 10.4.11, so there's a
chance it will mess up there.
In summary, this 0.5 modification workaround may work for you. Still,
it's a shame the behavior couldn't be reverted. Also a shame that
this floor vs. rounding cannot be fixed across the board for all
values. Please note too that I capped my testing to maximum offset/
blur of 9. You can definitely use larger values, so YMMV with the
workaround there.
The only thing I can think of as to why the workaround fails on some
offsets is probably due to someone doing multiple points of rounding
(rather than just rounding the final value). Enter in numerical
analysis. And, without actually seeing Apple's code, I can only guess
that we're now dealing with a compounding of rounding errors.
Finally, please note that all my offsets follow the rule of |xOffset|
= |yOffset|. So, if your offset values differ, this workaround may or
may not work for you. For my specific case, the workaround works great.
Oh...one final note. To the naked eye, the difference images looked
pure black. However, some pixels in the difference had RGB values
such that 1, 2 or 3 of the RGB components had a value of 1 (e.g. 0, 0,
1). Here, the values were viewed in Photoshop and thus have a range
of [0..255]. So a difference of 1 is very small on that scale.
I believe the reason for this is due to the slightly different color
profiles on my machine? I created a calibrated profile for my Leopard
installation much later than the one for my Tiger installation. If
you do this "difference" approach, you'll clearly see areas where your
shadows render differently. These extra subtle differences may be
there, but can be ignored.
___________________________________________________________
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
