I am trying to understand its usage better in order to improve scrolling performance on OSX. More specifically, I am trying to eradicate the "flashing/flickering" on the side of the screen as you scroll fast and AppKit runs into non-overdrawn (non-prepared) portions of your view OR portions of your view that have been prepared incorrectly with background-only.
My understanding is that the preparedContentRect represents the overdrawn section of your scrollview - the area available for responsive scrolling.
Part One
I placed code within the preparedContentInRect for two subViews of NSScrollView - each are floating subViews of NSScrollView which behave the same as documentViews when scrolling.
The preparedContentInRect gets called several times just after program launch (as expected). I then scroll to the end of the prepared area BUT (unexpectedly) it doesn't get called again as I get nearer and nearer and even on the edge of the prepared area. Why not? Even with no user interaction with the UI (system idle) it does not call preparedContentInRect to enlarge the overdraw area dynamically.
Part Two
Since (as above) I could not rely on AppKit calling preparedContentInRect when needed; I reorganised my code to prepare the preparedContentRect after each notification from the clipview's boundsChangeNotification and then call prepareContentInRect manually to inform AppKit of the new overdraw area.
I have included a "manual" flag so that my custom override can differentiate between my manual calls to prepareContentInRect and internal calls from AppKit - so as not to let AppKit mess up the overdraw!!!
var manuallyPrepareContentInRect = false
override func prepareContentInRect(rect: NSRect) {
if manuallyPrepareContentInRect{
println("GRID manual prepareContentInRect call: \(rect)")
manuallyPrepareContentInRect = false
super.prepareContentInRect(rect)
return
}
println("GRID bypass AppKit prepareContentInRect call: \(self.preparedContentRect)")
super.prepareContentInRect(self.preparedContentRect)
}
Unfortunately, even though prepareContentRect is reporting my intended prepare rect, when it scrolls it does not seem to have prepared the rect as I have intended - it prepares a rect 3,500 points wide instead of 5,040 wide and hence I run into the dreaded background color while waiting for the rest of the view to render.
The only "special" thing about the view that isn't getting correct overdraw is that it has a whole lot of subviews that have been drawn into its layer using canDrawSubviewsIntoLayer.
What am I misunderstanding above with respect to prepareContentInRect and overdraw? Why is AppKit behaving like it is?
Related
I am creating a popup menu. It has a UIPresentationController that calculates frameOfPresentedViewInContainerView based on presented view controller's view size before showing it.
Presented view controllers consist of the fixed height outer (navigation) view controller embedding some dynamic height inner (content) view controller;
Inner view controllers, under the hood, have UIStackView wrapped in a UIScrollView;
Before calculating size of inner view controller I am calling layoutIfNeeded() on it.
The problem occurred only on devices with the notch (I blame safeAreaLayout) and only with a UIStackView-based inner view controllers. When layoutIfNeeded() called on presented controller (e.x. when display orientation change, content size change, or presented second time) UIKitCore goes into an infinite loop calling -[UIView layoutGuides]. It doesn't crash the app, but use 100% of the main thread and freezes the UI(sometimes whole phone to the point you need make a hard reset), consuming about 10Mb of memory every second.
I was able to fix it by adding 1 extra point to a calculated height of the frameOfPresentedViewInContainerView. This sounds like an awful fix, so I am trying to better understand the problem.
I would be glad if someone with a deep understanding of UIKit could point me to a better strategy on how to debug/investigate the issue.
UPDATE
Seems like UIScrollView having hard time positioning content due to a safeArea. UIKitCore keeps repeating those 5 lines:
- [UIScrollView _layoutGuideOfType:createIfNecessary:]
- [NSISEngine(_UILayoutEngineStatistics)_UIKitPerformPendingChangeNotifications]
- [UIView layoutGuides]
- [_UIScrollViewScrollIndicator _layoutFillViewAnimated:]
- [UIView(AdditionalLayoutSupport) nsli_lowerAttribute:intoExpression:withCoefficient:forConstraint:onBehalfOfLayoutGuide:]
I also have
runtime: Layout Issues: Scrollable content size is ambiguous for UIScrollView.
I was able to fix my issue by specifically attaching UIScrollView to the bottom of safeAreaLayoutGuide.
var bottomConstraint = formView.bottomAnchor.constraint(equalTo: view.bottomAnchor)
if #available(iOS 11.0, *) {
bottomConstraint = formView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor)
}
I'm new to CAShapeLayers so forgive me if this is an obvious fix. Im trying to move a line in sync with a UIScrollView when the view is moving up but keep the line still when the scroll view is moving down. I am using a delegate to detect when the scroll view is moving and this is my code for changing between the visible line.
func scrollViewDidScroll(_ scrollView: UIScrollView){
if(mainScrollView.contentOffset.y < CGFloat(0.0)){
topMainContentViewLine!.isHidden = false
largeRocketImageView!.isHidden = true
topViewLine!.isHidden = true
}else if(mainScrollView.contentOffset.y == CGFloat(0)){
topMainContentViewLine!.isHidden = false
topViewLine!.isHidden = false
}else{
largeRocketImageView!.isHidden = false
topMainContentViewLine!.isHidden = true
topViewLine!.isHidden = false
}
}
When I run my app I can easily see that the two lines are fading in and out instead of appearing and disappearing instantly. For comparison the image has no animation. Any ideas on how to get rid of the animation? Thanks again!
From the documentation:
https://developer.apple.com/documentation/quartzcore/calayer/1410838-ishidden
isHidden
A Boolean indicating whether the layer is displayed. Animatable.
See that word "animatable"? That is a rather tight shorthand; it means that when you set this property on a layer that is not the underlying backing layer of a UIView (e.g. any standalone sublayer), animation is the default. That's called implicit layer animation.
If you do not want animation of an animatable property under those circumstances, you can turn animation off by calling
CATransaction.setDisableActions(true)
You can do that either for a specific explicit transaction block (i.e. everything between matching begin() and commit() commands), or for the entire implicit transaction in which all your code runs.
More commonly, if you have a layer for which you always or mostly don't want animation, you'd host it as the underlying layer of a custom UIView. In that case, setting an animatable property would not animate, and if you needed animation, you would use an explicit CAAnimation (or UIView animation) to get it.
For comparison the image has no animation
Because largeRocketImageView is not, itself, a layer; it's a view.
I have a UICollectionView which shows images retrieved from the web. They are downloaded asynchronous.
When user scrolls fast, they see placeholders until the cell loads. It seems UICollectionView only loads what is visible.
Is there a way to say "collection view, load 20 cells more above and below" so chance is higher that it loaded more cells while user was looking at content without scrolling?
The idea is to have the VC recognize when a remote load might be required and start it. The only tricky part is keeping the right state so you don't trigger too much.
Let's say your collection is vertical, the condition you want to know about is when:
BOOL topLoad = scrollView.contentOffset.y < M * scrollView.bounds.size.height
or when
BOOL bottomLoad = scrollView.contentOffset.y > scrollView.contentSize.height - M * scrollView.bounds.size.height
in other words, when we are M "pages" from the edge of the content. In practice though, this condition will be over-triggered, like when you're first loading, or if you're testing it on scrollViewDidScroll, you don't want to generate web requests for every pixel of user scrolling.
Getting it right, therefore, requires additional state in the view controller. The vc can have a pair of BOOLs, like topLoadEnabled, bottomLoadEnabled, that are NO until the view is ready. Then, scroll delegate code looks like this:
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
// compute topLoad and bottomLoad conditions
if (topLoad && self.topLoadEnabled) [self startTopLoad];
similarly for bottom. The load code looks like this, abstractly:
self.topLoadEnabled = NO; // don't trigger more loading until we're done
[self.model getMoreTopStuff:^(NSArray *newStuff, NSError *error) {
// do view inserts, e.g. tableView.beginUpdates
self.topLoadEnabled = YES;
}];
Same idea for bottom. We expect the model to fetch for itself (maybe the model has image urls) and cache the result (then the model has images). As the datasource for the view, the view controller gets called upon to configure view cells. I can just naively ask the model for images. The model should answer either fetched images or placeholders.
Hope that makes sense.
In my opinion you are making the wrong assumption: cells are just views so you shouldn't treat them as model objects. UICollectionView and UITableView are very efficient because they constantly recycle cells so you should think in therms of pre loading content in the business side of things. Create interactor or viewmodel objects and populate your data source with those, then you'll be able to ask those objects to preload images, if you still wish to do so.
A BOOL flag seldom is the answer. I'd rather go for estimating a reasonable page size and fetching images as needed from the cellForItemAtIndePath method.
I have a flow panel with many photo-widgets inside (gallery with random number of rows and columns, depends on screen size) for which I want to implement drag and drop behavior to change their order. I am using gwt-dnd library. Its FlowPanelDropController allows you to define your own positioner (delimiter) which shows the candidate location for dropping the dragged widget.
I want this positioner to be the empty space with defined width, and the challenging thing is to implement sliding animation effect for the when positioner is added and removed.
If you are a desktop Picasa app user you know what I mean: the target row slides both sides (little to the left, little to the right) extending the space between the items where you are going to drop a photo.
The whole thing is complex enough, but any help related to how to apply the animation for positioner attach/detach is appreciated. Maybe I need to use a different approach (e.g., use GWT native dnd instead of gwt-dnd lib and no "positioners" at all) if you have any ideas how this could be helpful.
Thanks.
Well, I ended up overriding AbstractPositioningDropController (parent of FlowPanelDropController) and adding some extra features.
1) newPositioner() method now builds the Label, which is vertical space with some small width, height and decoration. This widget's element has constant id (say, "POSITIONER"), which helps to distinguish between multiple positioners if you plan to have several of them while navigating with a drag object over multiple drop targets. Also some transition CSS effects were applied to the Label, which will be responsible for handling animated extension of Label's width.
2) in onEnter() I do the following
...
removePositioner(getPositionerElement());
Widget positioner = newPositioner();
dropTarget.insert(positioner, targetIndex);
animatePositionerExtension();
where getPositionerElement() returns DOM.getElementById(POSITIONER)
At the same time removePositioner(..) resets the id of this element to something abstract and ideally should provide some animation before calling .removeFromParent(). But I didn't have enough time to properly debug this so ended up just removing the old positioner with no animation.
Method animatePositionerExtension() contains the code that changes the width of the positioner widget, so that CSS transition will catch that and provides animation.
All access to positioner widget in the class should be provided through updated methods.
3) onLeave() contains line removePositioner(getPositionerElement());
4) In the end of onMove() I added a couple of lines:
galleryWidget.extendHoveredRow(targetIndex - 1);
animatePositionerExtension();
where extendHoveredRow(hoveredWidgetOrdinal) implemented the logic to "limit" the sliding effect in the single line:
int rowHovered = -1;
public void extendHoveredRow(int hoveredWidgetOrdinal) {
int newRowHovered = getRowByOrdinalHovered(hoveredWidgetOrdinal);
if (rowHovered != newRowHovered) {
// adjust position of items in the previously hovered row
int firstInPreviouslyHoveredRow = (rowHovered - 1) * itemsInARow;
shiftFirstItemLeft(firstInPreviouslyHoveredRow, false);
rowHovered = newRowHovered;
// extend this row
int firstInThisRow = getOrdinalFirstInThisRowByOrdinal(hoveredWidgetOrdinal);
shiftFirstItemLeft(firstInThisRow, true);
}
}
This is in short how I did the thing. And still there's some room for improvements, like adding animated removal.
Again, it's all about overriding DropController and manipulations with elements inside the "gallery" widget. The benefit of this approach is that I remain in the gwt-dnd operations framework, and also reused a bunch of existent code.
Some notes:
CSS transition is not supported in IE pre-9, but this is unrelated to
this topic.
Put a transparent "glass" div on top of the Image widget if you use it
as a face of dragProxy. This will save you tons of time trying to
understand why either setting element's draggable to false, or
calling event.preventDefault() somewhere else, or other workarounds don't work in one or several browsers and the image itself is being dragged instead of the whole dragProxy widget.
In GTK (or pygtk or gtkmm...)
How can I detect that an application window has been manually resized by the user, as is typically done by dragging the window's edge?
I need to find a way to differentiate manual resizes from resizes that originate from gtk, such as changes in window content.
Have you tried connecting to the GDK_CONFIGURE event?
Check out this example under the
"Moving window" section. The example shows a callback doing something when the window is moved, but the configure event is a catch-all for moving, resizing and stack order events.
I managed to pull this off by watching for size_allocate and size_request signals on the GtkWindow. If size_request ever got smaller, I called resize(1,1). If size_allocate was ever bigger than expected, I turned the system off.
One thing I made sure to handle was size_request returning big, then small, and having size_allocate be big and then small. I don't know if this is possible, but I fixed it by making sure to only decrease the expected values for size_allocate when I got a smaller size_allocate, not when I got a smaller size_request.
Make sure that your size_request handler comes after the base class' handler so that you get the right values. I did this by overriding the method and then calling the base class method first.
I've tried this in both 1 and 2 dimensions and it seems to work either way.
In my case I was trying to distinguish between a user resizing a Gtk.Paned from the user resizing the whole window. Both emitted the notify::position signal.
My solution was, since I can't know if the user is resizing the window from the widget, reverse what I wanted to know. Record if the user has re-positioned the widget and ignore updates if the user didn't initiate them on my widget.
That is to say, instead of testing "if window being resized" I recorded the button-press-event and button-release-event's locally so I could instead test "if widget being re-positioned"
from gi.repository import Gtk
class MyPaned(Gtk.Paned):
_user_activated = False
def on_position(self, _, gparamspec):
if self._user_activated:
# widget touched
else:
# window resized (probably)
def on_button_press(self, *_):
self._user_activated = True
def on_button_release(self, *_):
self._user_activated = False
dev __init__(self, *args):
super(MyPaned, self).__init__(*args)
self.connect('notify::position', self.on_position)
self.connect('button-press-event', self.on_button_press)
self.connect('button-release-event', self.on_button_release)
Effectively by recorded when the user started and ended interacting with my widget directly, I could assume the rest of the time was due to the window being resized. (Until I find more cases)
In PyGTK, I've always watched for the expose_event for a window resize, then use the get_allocation method to get the new size.
You may be able to throw something together by using gdk_window_get_root_origin to get the top left corner of the window and gdk_window_get_geometry to get the width and height. Then you could hook a callback into the GDK_BUTTON_PRESS_MASK and check to see if the button press occurs near/on one of the edges of the window.
Of course, this seems quite hackish and it really bothers me that I couldn't find some simple way in the documentation for GdkWindow to do this. There is a gdk_window_begin_resize_drag function which really makes me think there's a cleaner way to do this, but I didn't see anything more obvious than my answer.