Stay constraints about kiwi HOT 8 CLOSED

I omitted stay constraints in my version. I found that for my purposes of typical application layout they weren't needed (such systems are typically well-constrained).

From what I've seen, stays are useful when doing pick-and-move type operations where the system is naturally under-constrained and the stays are needed to make it well-behaved.

Kiwi is fast for a couple of key reasons:

• There are no virtual functions in kiwi. Virtual classes take longer to instantiate and have non-trivial copy-semantics. The only exception is for the user data variable context, which is never copied.
• Variables are replaced in the solver with trivially-copyable symbols.
• Maps are implemented using sorted vectors instead of node-based containers. This makes them very cpu-cache friendly. Most of the speed and memory wins come from this point. Recompile after uncommenting this line and see for yourself (the difference is huge): https://github.com/nucleic/kiwi/blob/master/kiwi/maptype.h#L31

from kiwi.

It's good to hear stays can be removed without a problem for doing GUI layouts, I'll definitely give that a try and see if anyone actually misses them. Replacing the big polymorphic variables with symbols is also a very good idea! (I had already replaced all maps with sorted vectors and unordered_maps, might be a trivial optimization but like you said, it makes a huge difference.)

Thank you for the detailed answer!

from kiwi.

Is there any way to work around this (read hack), or extend current code base? I'm not very (read barely) familiar with the implementation-details of cassowary & stays, but they are vital in my case since I use the solver in a "drag-n-drop" editor which is at most times under-constrained...

Is it possible without too much trouble?

from kiwi.

You can probably work-around it by adding non-required == constraints for the variables which should remain in their current location. When editing parameters, remove the the == constraints and use suggestValue for the variables which should be edited.

from kiwi.

Yeah thought about that, but I want to avoid this since then I have to keep adding/removing constraints when moving vars around which might cause performance issues...

Just looked over another implementation of cassowary and stay-constraints seem to be highly embedded (lots of nasty if/else special cases), which is what I feared.

from kiwi.

In my experience cassowary is solving things very quickly. I wouldn't worry about performance issues.

from kiwi.

Been having some issues with older implementations which is why I set my hopes for this one, but then again I'm running on mobile devices so every inch counts!

But yeah I might be able to mimic it with equal-constraints without to much effort... :)

from kiwi.

I'm also on mobile c++ (ios). The java implementation seems slower.

from kiwi.