We have a neat feature in our mouse hinter: we do compute the edge intersections and we provide as helper points. As the code will compute all combinations between edges, and edges can be really a lot in some shapes, we improved greatly performance using:
- we precompute edge intersections instead computing them real time. This will make a huge difference in how your mouse will work
- clustering: we compare edges against different shapes only. This may not sound as efficient but combined with fact that we compute that just shapes with common bounding boxes will make the comparison count much less
Spline implementation is powerful yet a bit imprecise. The reason is that our spline implementation is not limited at "patches" of 4 points (two end points and two control points), but use as many points as possible. A preview code (it is not time to be finished till release) will make possible to make a full spline based on this design. Also, combined with previous changes that a solver will forward compute references, it makes that all infrastructure to make those splines possible.
A small "fix" is that GC is called after some predictable moments, giving a small overhead virtually at every click (around 5 ms), but will make other things better as GC will unlikely run unexpected. So you will feel a much pause-less experience on low end machines. Some pauses will still appear anyway, because we have areas that are still slow in our code-base (mostly the WPF tree and some solver computing, as was already said, but in long term we will fix those).
More bug fixing was done to overcome some of more radical changes around.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment