I got a problem with Cocoa and its View redraw hierarchy.
I'm currently testing displaying (audio) levels in a meter style control and I'm using the MeteringView class from MatrixMixerTest example project from apple. This class is drawing the meter and only drawing the difference what got changed which looks like a very efficient class.
My project is splitted into 2 splitviews, in some are NSCollectionViews (Scrollview, Clipview) and in others are only static views. If I add the meter to those "static" views they work fine when these views call setNeedsDisplay:YES. If a meter is added to the view of a CollectionView Item it gets rendered, but loosing its drawn "old level" parts and its corners/background. I think this happens because the CollectionView item gets also called to be redrawn (which has a background image) and everything is gone. It is drawing some parts whats currently changing (the drawing works).
Is there a way to prevent the Item itself to be redrawn? Or, I dont know why it is not happening in those static views, because those views also have background images but do not draw over the meter.
Are there some tricks or whats different in a CollectionView than in a "normal" view?
EDIT: After reading about isOpaque (MeteringView isOpaque = YES) means it should not call the parent views drawRect if set to yes. Well that works for the static views, those MeteringViews do not call parents drawRect, but those in a CollectionView do however. I dont know why.
EDIT 2: I gave this topic another title, because isOpaque=YES in MeteringView is not stopping calling the parents drawRect in a CollectionView, in a normal view it is working. Are there some things to know about? I have to stop redrawing the CollectionView Item because thats the problem.
Thanks in advance guys
Benjamin
isOpaque is just hint to the system. It does not prevent other views from drawing their contents, it only means that it can sometimes skip making other views update their contents.
If your view is opaque, it should draw itself as opaque and completely fill its bounds.
Related
I'm working on an app made by a NSWindow which own a lot of custom subviews, that could be opaque or not.
Whenever I call SetNeedsDisplay: or SetNeedsDisplayInRect: on a subview, the system calls the drawRect of each single subview starting from the content view of the parent NSWindows.
How can it be avoided? How can I redraw just the dirty subview (it should be the default behaviour)? Is there something that I'm missing maybe in subclassing the NSView? Or in setting the properties or the syle of the parent NSWindow?
Thanks
The that could be opaque or not is the trouble-some bit. Any non-opaque view triggers a redraw of the entire view hierarchy, because the window must restore that views background to a pristine state. Only views set to opaque may not require anything else below them to be redrawn. They might still trigger redraws "above" though, if the opaque view itself is partially covered by other views.
Ok, I think I’ve figured it out. It seems that turning all the subviews into layer-backed views did the trick.
And this is reasonable giving the way the layers are managed by the gpu and how the layer compositing is performed.
But I still don't understand why, using the "classic" NSViews, no matter if they are opaque or not, siblings or children, overlapped or not , I cannot invalidate a single view without the system calls the re-drawing of the entire view hierarchy of the window
I have a view with several subviews (NSButton, NSTextField, NSPopUpButton) and a NSImageView with a spinner icon which should be displayed on top of the other views while data is retrieved from the web.
To display the NSImageView on top I have set
imageViewSpinner.wantsLayer = true
imageViewSpinner.layer?.backgroundColor = NSColor.windowBackgroundColor.cgColor
The problem is, that the focus borders and PopUpButtons are still accessible/shining through the NSImageView (see attached video).
To solve this, I could iterate over all the other subviews and set them to "isHidden" or "disabled" but I wonder, if there is a cleaner solution to this problem, for example defining the NSImageView as topmost layer without things getting through?
You could put all of the other views inside of one container view and hide that.
You can also use a tab-less tab view to programmatically switch between view sub-hierarchies. (That basically achieves the same thing. It's better when there are more than 2 views to manage.)
Although I know of a solution to this problem, I am interested if someone can explain this solution to me. I also wanted to get this out there because I could not find any mention of this problem online, and it took me several hours over several days to track down. I have an NSTableView behaving strangely regarding redraws and its selection. The problem looks like this:
Table contents fades in, instead of appearing instantly upon it's appearance on screen. When scrolling through the contents, the newly appearing rows also fade in. When you make a selection (single or multiple), and scroll it off screen, then make another selection (that should replace, not add-to first selection), the first selection does not get cleared properly. If you scroll back to it, it is still there, in addition to your new selection. This is a display-update problem, not selection problem - i.e. your new selection is valid, it is just displayed wrong.
I tracked this through the NSArrayController I was binding to, the underlying Array, sorting, all the connections, and settings, etc., but all that has nothing to do with it.
What solved the problem was:
In the View Effects (right-most) Inspector, uncheck "Core Animation Layer" for the Window's main view.
Can anyone explain what is happening here, and perhaps improve upon the solution ?
It looks like Core Animation and NSTableView aren't getting along so well. The "fading" effect is a by-product of the way core animation works. When you have core animation in one view, it is also enabled in all of that view's subviews.
I don't recommend using core animation on the Mac unless absolutely necessary, because some interface elements (NSTextView and NSTableView, for example) aren't compatible with it. iOS has much better support for table views and such using core animation, mainly because it was designed with core animation in mind.
I know that some more simple UI elements are compatible (NSTextField and NSButton, for example).
If you absolutely need core animation in the rest of the window, put all the other views in a subview of the content view, while leaving the table view directly in the content view. You can then enable Core Animation in the other view.
Commenters, feel free to add to the list of what is and isn't compatible.
You see this in iPhone apps like Gilt. The user scrolls a view, and a subview apparently "sticks" to one edges as the rest of the scrollView slides underneath. That is, there is a text box (or whatever) in the scrollView, that as the scrollView hits the top of the view, then "sticks" there as the rest of the view continues to slide.
So, there are several issues. First, one can determine via "scrollViewDidScroll:" (during normal scrolling) when the view of interest is passing (or re-appearing). There is a fair amount of granularity here - the differences between delegate calls can be a hundred of points or more. That said, when you see the view approach the top of the scrollView, you turn on a second copy of the view statically displayed under the scrollView top. I have not coded this, but it seems like it will lack a real "stick" look - the view will first disappear then reappear.
Second, if one does a setContentOffset:animated, one does not get the delegate messages (Gilt does not do this). So, how do you get the callbacks in this case? Do you use KVO on "scroll.layer.presentationLayer.bounds" ?
Well, I found one way to do this. When the user scrolls by flicking and dragging, the UIScrollView gives its delegate a "scrollViewDidScroll:" message. You can look then to see if the scroller has moved the content to where you need to take some action.
When "sticking" the view, remove it from the scrollView, and then add it to the scrollView's superview (with an origin of 0,0). When unsticking, do the converse.
If you use the UIScrollView setContentOffset:animated:, it gets trickier. What I did was to subclass UIScrollView, use a flag to specify it was setContentOffset moving the offset, then start a fast running timer to monitor contentOffset.
I put the method that handles the math and sticking/unsticking the child view into this subclass. It looks pretty good.
Gilt uses a table view to accomplish this. Specifically, in the table view's delegate, these two methods:
– tableView:viewForHeaderInSection:
and – tableView:heightForHeaderInSection:
I am trying to create a view for a kind of brainstorming application like, for example, OmniGraffle, with elements that contain textviews and can be dragged around. (Also, the should be connectable with arrows, but that is not (yet) the problem)
I did my homework and searched via google and read books about cocoa, but there seems to be no similar example around.
Since I am also new to cocoa, I’m a bit helpless here.
The thing I am sure of is, that I need a custom view in which I can create my elements - what I tried until now to do that is:
First, I searched for the syntax to add subwindows to a window to create my elements. Subwindows, I imagined, would automatically be movable and come to front and so on.
The problem: As the experienced Cocoa-programmers of you probably are not surprised, I was stunned to find nothing about anything like that - this seems to be something, that is just not intended in Cocoa?!
Then I thought about creating subviews that contain a custom view for the title bar drawing (where the user can click to drag the element) and a NSTextView.
Problems:
I read, that it is not so clever to create dozens of subviews in a window because that would be very slow (or would that be not so bad in this case because all the subviews would be instances of always the same class?).
Also I can’t find out how to load a subview from a nib- or xib-file. Would I need a viewController? Or would that make the dozens-of-instances-problem even worse?
And Apple tells you not to overlap subviews (okay, that would be not so important, but I really wonder how the guys at OmniGroup made OmniGraffle...)
Because of that, I now wanted to do the title-bar-drawing in the surrounding custom view and create the textview programmatically (as I understand, a text-“view“ ist not really a view and takes its functionality from NSCell to reduce all the effort with the views?).
Problems:
Even that failed because I was not able to create a textview that doesn’t fill the complete window (the initWithFrame: of the [[NSScrollView alloc] initWithFrame: aRect] just seems to be ignored or do I get that wrong?).
Also, there should be some buttons on each element in the final application. I imagine that would be easier to accomplish with a subview from a nib-file for each element?
Well, now that nothing works and the more I read, the more problems seem to occur, I am pretty confused and frustrated.
How could I realize such a program? Could someone please push me in the right direction?
I created a class for the draggable elements where I save position, size and text in instance variables. In my view, every new element instance is added to an array (for now, this works without a controller). The array is used to draw all the elements in a loop in drawRect:. For the text of the element I just use a NSTextFieldCell which is set to the saved text from every element in the same loop.
That way it is also possible to overlap the elements.