Michele Spagnolo
Michele Spagnolo
@cbjeukendrup done, thank you! 👍
Ha! Great catch. That's because in #13218 I hadn't extracted the full direction logic, but only the "auto" portion of it. I've corrected that now
> It must be that the `_startSlur` of the first chord becomes the downwards slur, and the big upwards slur gets overlooked. Yeah, the chord is storing only one `_startSlur`...
> instead of vectors of slurs, we could store: `bool _startsOrEndsUpSlurs` and `bool _startsOrEndsDownSlurs`. I was curious to try this, but I've found that in fact the performance cost of...
I've optimized it further and made sure that the computation is performed only once per chord. The measured performance cost (i.e. the time taken to perform `Score::doLayoutRange()`) is now +5.5%...
By the way, when #13466 is merged, the performance cost of this PR will become much smaller, maybe even negligible. I'll wait for the other to be merged and the...
> Is it possible that it started after #12591? Or more recently? Yep, very likely it started there.
In fact I can confirm that setting setSmooth(true) in quickpaintedview.cpp fixes the issue, though obviously it brings back the "blurriness" that the PR wanted to address in the first place.
Still seems to happen unpredictably, no matter the zoom settings
What surprises me is that `styleChanged()` only acts on STYLED properties, i.e. properties which follow the score general style. Normally, when an item is customized, the connected property becomes marked...