Re: UIStackView: Variable Spacing
Re: UIStackView: Variable Spacing
- Subject: Re: UIStackView: Variable Spacing
- From: Fritz Anderson <email@hidden>
- Date: Thu, 07 Jul 2016 10:25:25 -0500
Confirming that your concern is now Auto Layout overhead?
---
Long, long ago, when there were no iPads or Auto Layout (2009?), the scrolling-performance session at WWDC said if your cells had nontrivial subview trees, and the table was stuttering, bite the bullet and start aggregating subview nodes into monoliths that you lay out and draw yourself.
iOS devices are an order of magnitude faster now, but that doesn’t solve the problem in principle, just puts it off.
---
Obviously it’s a lot of work to code (and maybe to execute — you’ll have to use trial-and-error to find an ad-hoc solution); ad-hoc makes refactoring harder; you’ll be spending your vacations in Caching Inferno; etc. You’d sacrifice Make it Right for Make it Fast. That’s supposed to be a smell, but in this case Make it Fast _is_ Make it Work.
I don’t know nearly enough about your application to say whether it’s an option. I’ve had reasonable success with splitting the difference and replacing leaf views with layers to relieve the combinatorial explosion AL risks.
---
If Auto Layout has no combinatorial risks, or surprisingly few, I’d be fascinated to know why.
— F
> On 6 Jul 2016, at 6:56 PM, Daniel Stenmark <email@hidden> wrote:
>
> It’s not so much that adding a single dummy view wrecks us. Our cell layout has a lot going on, with a fair amount of variable spacing and multiple views often being hidden and swapped out. The UIStackView scrolling performance slog I’m seeing is just sum of all that.
>
> Sigh, oh well. I guess that’s just another refactoring branch I’ll have to shelve for now.
>
> Dan
>
>> On Jul 6, 2016, at 4:45 PM, Roland King <email@hidden> wrote:
>>
>>
>>> On 7 Jul 2016, at 04:37, Daniel Stenmark <email@hidden> wrote:
>>>
>>> What’s the best way to achieve variable spacing between children of a UIStackView? I know that a popular approach is to add an empty dummy view to act as padding, but this is being used in a UITableView cell, so scrolling performance is critical and the implicit constraints created by adding a ‘padding’ view are a death knell for us.
>>>
>>> Dan
>>
>>
>> There’s no trick way to do it, you need some extra view one way or another.
>>
>> It’s a bit surprising that adding extra, fixed sized children to the stack really adds that much overhead, that’s a few very simple constraints, all constant, and shouldn’t really make that much difference. Perhaps the stackview is being inefficient with the number of constraints it adds when you add an extra child. You could take a look at the view hierarchy and see if that’s the case or not.
>>
>> You could try going the other way around and making your real elements children of dummy views so you get to add the simplest top/bottom-padding constraints possible to those views, that may minimise the number of extra constraints added and you get to control it somewhat. But if your hierarchy is such that it’s straining the constraint system performance wise, whatever way you try to do this is going to have similar performance.
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden