Palette symbols reduced in latest nightly, and possible text rendition issue (?)

• Jan 6, 2016 - 15:12
Type
Functional
Severity
S4 - Minor
Status
needs info
Project

Nightly d08e14c (4 Jan 2016) / Win 7 HP (< 100 dpi)

The zoom level is now correct in the latest nightlies in Win 7. But:

1. Palette symbol size is reduced by, perhaps 80%, compared to the size in the previous official MS 2.0.2 release. See attached screenshot – MS 2.0.2 on top, nightly at bottom.

2. The rendition of text objects At (100 or 200 % mag.) looks marginally worse than it did in previous versions. Close examination of the screen shows that there is a change in the distribution of shading between the pixels comprising the text, but whether it's enough to qualify as an issue I can't say.

Attachment Size
palette_symbols_reduced.PNG 24.73 KB

Comments

Status (old) active needs info

I'm not convinced this is not the correct behavior. Prior to the DPI change, palette sizes were all over the map, differing from system to system depending on the display characteristics and generally not reflecting the actual sizes of the elements. The intent is that now, the elements *should* match the actual element sizes properly, after taking into account the scaling built in tho the properties for the individual palette (right click, Palette Properties). So for instance, the clefs palette is set to 80% scaling, and with the current code, what should happen is that clefs in the palette display exactly 80% of the size of any actual clef (for a score using the default 1.764mm spatium and 100% zoom), regardless of your display resolution. Wherewas previous, the actual sizes of the palette items were dependent on display resolution. So some people might see palettes look bigger than before, others smaller than before, others may see no change, but the point it, they should now be the *same* on all systems, and exactly as they should be given the scaling.

Which is to say, there was a bug in 2.0.2 causing the sizes of palette items to be incorrect, this bug is now fixed. Comapring to 2.0.2, you *should* therefore expect to see a change (unless your system happened to be one in which the old buggy algorithm happened to yield the correct sizes).

For more information, see the discussion in https://github.com/musescore/MuseScore/pull/2296

I'm not saying there couldn't still be an issue on certain systems - certainly we know scaling is not going to be correct on high DPI systems still running Windows 7 or older - but don't take 2.0.2 to be "correct", because it is not. Compare against the *actual* sizes of the elements in a score with default spatium, after taking into account the palette scaling.