MKAnnotationView not drawing transparent PNGs properly - cocoa-touch

I am having trouble getting my custom MKAnnotationView to render with proper alpha blending on its edges. As you can see from the following screenshot, the red and green dots have an ugly black edge that does not blend into the background, but the system-supplied user location (the blue dot, barely visible) does not.
The image is a transparent PNG and I have confirmed it's not the image's fault as it renders properly elsewhere.
I have set opaque = NO on the MKAnnotationView but it had no effect.
Am I missing something?

Ha, well it went away on its own. I'm honestly not sure what I did but I wasn't even worrying about it, changing some other stuff around and all of a sudden it renders properly now.
*shrug*

Related

Text flickers while animating on OSX

I have an NSView with white text against a black background. The view animates slowly up and down (+/- 10 pixels every 1.5 seconds), and the text visibly flickers while animating. It doesn't flicker a lot, but enough that it's noticeable when trying to read it. I've tried animating both with NSAnimationContext and CABasicAnimation.
This doesn't happen with the exact same design/animation on iOS, just on OSX. It might have something to do with the screen refresh rate, but it's driving me nuts and I figured I'd ask in case there was a simple solution.
The effect you describe is even more pronounced if you animate diagonally. I thought it might be diminished if one turned on shouldRasterize, but it's not. It feels as if it is to be an anti-aliasing of the narrow strokes of the font as the image animates through non-integer positions during the animation. The effect is curiously diminished if you use bold fonts. Also, the problem appears to be unrelated to the NSTextField, because if I take an snapshot of the NSTextField, remove the text field, and animate an NSImageView, the flickering is still apparent.
Bottom line, the effect is diminished with bold fonts. It feels like there should be an anti-alias feature one could turn off, but it's escaping me at this point.
I just happened to start using Facebook's Pop Animation framework in my project, and when I implemented a POPBasicAnimation for this animation the flickering seems to have disappeared completely - even for non-bold text.

Custom NSButtonCell rendering and default buttons

I've recently come across a problem with a custom NSButtonCell subclass. We have a dark interface with white text, and all is going as expected, until we try to make a default button (i.e. assigning a key equivalent of \r). What we get seems mysterious: The bezel draws, but the text doesn't. But if I make the text black, it draws. If I make the text white with a black shadow, only the shadow draws!
The mystery started to unravel when I tried a test with the text set to [NSColor redColor] on a lark. (The "Create" button here has a key equivalent of \r, "Cancel" is Esc.)
What I eventually figured out is that the default button's cell is drawing into a bitmap context, presumably so that the rendered glyphs can be cached for the animated blue pulsing background that the Aqua look gives. That makes total sense, but the surprise is that that bitmap is then drawn with a multiply compositing operation. Hence black shows up and white doesn't, and anything in between shows up darkened.
I've managed to hack a workaround, by taking the text rendering out of -drawTitle:withFrame:inView: and doing it in -drawBezelInFrame:inView: instead. But that gets called repeatedly, so I'll need to manually cache the image. Plus it's just conceptually ugly, because it's specifically the wrong method for rendering the title!
My question: Surely there must be a better way, right? Is there some way to tell the button cell not to automatically use this offscreen rendering path even though the button is default?

Poor font rendering (Cocoa - Mac)

I've noticed a strange and very noticeable difference in font rendering in my xib and my final program, I've attached screenshots below:
See here for zoomed out image
See here for zoomed in
What is going on here and how can I make my app font look like it does in XCode? (Does it have something to do with subpixel rendering???).
I stole this answer from here:
If you have no background (including clear) and your text is a subview
of any layer-backed superview (you've turned on "wants layer" in code
or in IB to allow animations/transitions), you'll get blurry text. You
have to choose either no layer backed view or a label with a solid
background color.

iphone - Making a MKMap black and white

There's a thread that asks the same thing, Black and white overlay for an MKMapView
but I have my doubts if the answer will work, no-one claimed to get it done.
A filter is a function applied to the pixels of an image, so making a Overlay with a monochrome filter will only be applied to the Overlay, not to the map.
Am I right?If not please tell me so, If Im right do you know any other way to make a MKMap to appear in B&W?
Thanks.

Chaning the background color around a PDF in a UIWebView on Device

I'm using a webview to display a PDF.
The webview displays the PDF at it's actual size which is a little smaller than the size of the webvieww itself, revealing the scroll view underneath it.
I've tried setting the Webview to opaque and setting it's background color to another color, which works fine and dandy in the simulator, but fails to change the color on the device. On the device it changes the color of the background of the view behind the scroll view, this can be seen when the PDF is pulled all the way down.
I've also tried setting all the UIView's backgrounds, by iterating through the subviews but to no avail.
I've updated a diagram to help illustrate which area I'd like to color.
Uploaded Diagram
You really shouldn't mess around with UIWebView's internals.
They can change anytime and your code might just crash on the next version of iOS.
If you need more control about pdf display, you might wanna take a look at other possibilities to show pdf, like using the CGPDFDrawPage* functions. Of course they are pretty low-level and it's a lot of work required until you can get fast page display, zooming, etc all right.