Calculations of the visible rect can be a heavy operation as it depends of the superviews
visible rect. They have to be transformed and intersected together to create the result.
This calculation is a recursive operation that travels up the view hierarchy all the way
to the top.
Updating the tracking areas is also a recursive operation. But it travels down the view hierarchy
instead. It will calculate the new tracking area using the visible rect for the current view. For
each view it updates it will get the visible rect that has to travel all the way up the view
hierarchy to calculate it by transform and intersect them together. This results in that the visible
rect will be calculated for each view multible times. This makes it a very slow operation, specially
for deeper view hierarchies.
This fix will send along the visible rect for the superview when traveling down the
view hierarchy. This means that the visible rect does not need to travel up the view hierarchy
to be calculated. It will just need transform and intersect the provided rect for its superview
with the one from itself.
This makes updating views much faster when they need layout. This will make resizing browser window and changing split views sizes much smoother.
The effectiveAppearance is inherited from the superview. The superviews appearance is passed along as it is recomputed down the view hierarchy.
Also the current appearance is saved on each view to make it possible to only change the theme states when the appearance is changed.
This speed improvement is very notable when resizing a browser window of altering the size of split views.
The fix uses a variable on the window to control when to update the tracking areas.
If the view is not connected to a window the tracking areas will not be updated as they will
be when added to a window.
Also fixed CPView -(BOOL)inLiveResize
If a view is added during a live resize, it will not receive a
willStart notif.
If a view is removed during a live resize it will not receive a Didend
notif.
Previously, during frame updates, we were writing the css values we
just read before.
Canvas sizing is preserved as it is needed when the view has custom
drawing.
Fixed: When only animating frameSize, there’s no matrix defined. This is now
correctly handled.
New: The animator can explicitly request frames updates when the frameOrigin
keyPath changes with the new method [animator setWantsPeriodicFramesUpdates:YES]
When a view belonging to a CPViewController is hidden, unhidden, added
or removed, its viewController receives the appropriate message.
Added AppKit/CPViewControllerTest.
Previously, when double-clicking on a table cell to edit it, there was a possibility of a race condition. A refresh of the display was requested, then the run loop was passed through once. But it was possible for the display refresh to not be queued when the run loop was passed through, in which case the refresh would cancel the editing. Or at least I think that's what was happening. ;-)
This commit (hopefully) eliminates the race condition by synchronously refreshing the layout and display.
Made some miscellaneous formatting fixes as well.
For some (yet unknown) reason, when declaring a view with tracking area
in a CIB, there’s some weird things happening that try to use the
_trackingAreas array when it’s not yet initialized… So, replacing
_trackingAreas.length by [_trackingAreas count] resolves the problem.
Didier KorthoudtandGitHub
Martin Carlberg
Didier Korthoudtandcacaodev
daniel
Didier Korthoudt
daboe01
Alexandre WilhelmandGitHub
Aparajita Fishman