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.
Related
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?
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.
I'm drawing some custom shapes behind a textview to make it appear it's a notepad. It draws a repeating bitmap across the top, as well as a white background under the text, and a secondary "note" page under the rest to add a little dimension and layering. See the screenshot:
Now, this is with setDrawingCacheEnabled(true) for the TextView this drawable is applied to. With this method call applied, the scrolling is VERY smooth, exactly what I want. Without it, the black background disappears, but the scrolling is very choppy. Any idea on how to cache this view so that scrolling is smooth without destroying my UI?
Seems this function only works with solid colors, as defined in the documentation which I should have read before posting. I find it hard to believe there's nothing that caches complex views and drawables to work as well as that function does, but, whatevs. Live 'n learn.
If you can edit the title and make it shorter, good on ya. Which is to say, sorry for the title length :P
In the HIG:
http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html
Scroll down to the section "Window Frame Controls". Buttons with NSTexturedRoundedBezelStyle draw differently when placed in an NSToolBar (darker gradient).
Putting HIG questions aside, I need the darker bezel for a button that is not in the window frame. It seems there is some flag which I am missing.
I can obviously just draw it myself, but wanted to check if there's just something totally obvious I am missing here?
Kind regards,
Alec
As of Lion, the Round Textured button is translucent, which means that some of the background shows through it. That's why it looks different in the toolbar, because there's a darker background behind it.
There is no magic flag to change this behaviour, the only way to give it a darker appearance would be to place it on a darker background.
I have an UITableView in my application, which is in an UIView that has it's background colour to the Scroll View Texture thing. This is all in an UIViewController. It works all nicely and stuff, but I get these fugly black corners around my table view edges:
The Background colour of the table view is set to the clear colour, and those squares even appear in Interface Builder. Any ideas on how to eradicate these evil UI blemishes? They make my UI look like something that was thrown together in 3 minutes, even when I spent more than a week designing my entire UI. It makes me want to punch UITableView in the face, too.
Quite strangely, setting the background to clear in code seemed to solve it for me. It is a really weird issue, and I submitteda bug report to Apple about this, although their bug reporter needs it's own bug reporter.
Also make sure the background color is not just clear color, but that opaque is NO.