Guitar Tab fret numbers have a visible white box behind them

[Tantacrul]

Describe the bug

These white boxes need to be set to match the 'Paper colour', which is set in preferences.

Looks really bad if you change the score background colour to anything other than white (by default we don't use white).

Here's how they look when the score is inverted:

[abariska]

@Tantacrul wow! almost invisible issue, great catch)

[Tantacrul]

🥇 for me!

I guess we'll also need to be careful that by fixing the colour problem, they still appear white when exported as PDF :)

[cbjeukendrup]

The real solution would be not to draw a background at all, but make a gap in the staff lines. That way, it would also work correctly when exporting transparent PNGs or SVGs. I believe the reason that it is not done yet that way, is that it's difficult :)

[Tantacrul]

@cbjeukendrup - it does seem to have been done for MuseScore 3 though?

[cbjeukendrup]

MU3 uses the workaround of using the background color of the page. But when exporting to transparent images, indeed it does not work:

[Tantacrul]

Better than what MS4 does, at least :)

I do agree with your suggestion for what we should actually do, of course :)

But at the least, we should match MS3.

[SonnyRR]

Any updates on this issue ? I really prefer the all-dark feel because I usually use it at night. But using tablature as linked staffs is unreadable to me unless I use non-inverted scores.

[Tantacrul]

@bkunda / @oktophonie / @mike-spa - it'd be lovely to fix this. It's such a dumb issue that surely has the simplest fix known to man.

• Hack solution: make the squares the same colour as the BG.
• Proper solution: implement a way to 'cut out' or mask out stuff around the numbers. It's a thing we need elsewhere anyway (dynamics on barlines for example)

[cbjeukendrup]

A while ago, I had thought of an implementation of the "proper solution". However, I never talked about it because it would bring some significant complications, with potential performance implications.

But to elaborate: it is possible (with QPainter) to clear pixels instead of drawing on them, using the SourceOut composition mode. But this will completely clear the pixels that you touch with that painter: even the pixels of the score page background below the actual score. So it will basically create a gap in the whole UI.
The solution would be to draw the notation elements to a separate buffer first, like a QImage; that way, only the pixels of the QImage would be cleared. Then, in the notation view, draw the background and page background, and then draw those QImages on top of that.

The difficulties of this solution are:

1. I'm afraid that the temporary QImages will have a big performance cost. We won't know how big exactly until we try it out; but we'd need an estimation to be able to answer the question whether it's even worth trying out.
2. It seems difficult to realise for SVG export. It looks like SVG does not really support something like this, so the closest I could get is some hacky stuff with masks. My conclusion was that it's definitely doable, but just requires a bit of cleverness. Slightly more cleverness would be needed to somehow optimise the generated SVGs, because I'm afraid they will quickly become very complex if we don't watch out.

[Tantacrul]

I wonder if we shouldn't just try to implement a system where barlines and stafflines can have gaps in them to accommodate other elements clashing with them? In other words, that the vectors 'know' how to redraw themselves?

[mike-spa]

The ability to mask vectors is something we would really need, for several purposes. I'm not sure drawing background rectangles is a general solution: it can work for the examples you mentioned (possibly adapted to the different background colors in UI and in print), but as soon as you get into situations like this

(the ties should be masked when intercepting the time and key signatures) things would become quite messy. [Side note: this has been on my wish list for a while. Finale will even mask these ties automatically. In Musescore, as far as I know, it just isn't possible.]

So I'd really love to work out a good solution. Which would look ideally like Martin said: it's the tie vector that should know how to interrupt itself where needed, rather then the key and time sigs knowing how to cover what's behind them. @cbjeukendrup I've also been thinking about this for a while. Are you sure that this can't be done by applying a clipRegion to the drawing path of the tie (or tab line, or bar line...)? When I looked into it a while ago, this kind of solution looked quite close to what we'd need, unless I'm misunderstanding it. Or would it cause the same problem you mentioned with the background also being erased?

[cbjeukendrup]

To be honest I haven't looked a lot into using clipRegion, but it looks like that would certainly work for ties. However, it does require that the cut-out rectangles are known at the moment that the element that needs to be cut is drawn (i.e. the tie), rather than at the moment that the element that's drawn on top of it is drawn (i.e. the time signature). Basically, with clip rect, you are leaving some space open in advance, instead of drawing on it and then clearing it later whenever that turns out to be necessary. That's doable, also for the fret numbers, but then the staff lines will just need to be informed about the positions of any regions that need to be cleared.

Another issue is that this approach will only work for shapes that can be described using a QRegion. That means, only relatively simple shapes. Clearing the shape of an element, like what's necessary for those noteheads with note names inside them, would not be possible using that approach. The erase method does allow to erase any shape that can be drawn.
Also, the documentation seems to suggest that things like this are not the primary purpose of clipRegion, but that it's rather designed for optimisation purposes (like not drawing anything that's currently outside the viewport).

On the other hand, a possible advantage is that (if the necessary data is calculated at layout time) the clip rect approach does not depend on the order in which things are drawn; the erase method does.

I would need to investigate whether the clip rect approach would work with SVG out of the box; I fear it doesn't, but that seems at least easier to overcome than with the erase method.

The approach that Martin seems to suggest is of course also still an option: just do the calculations ourselves and split the staff lines into multiple pieces with gaps between them, instead of relying on advanced painter features. That will work with SVG for free. But it is less general, so would need to be implemented for each case individually. And the possibilities will be quite limited; we can only split the line into pieces and each piece will have a rectangular end.