About the recent change with DPI and freetype in master
For those of you who are following the development closely, you may have seen 2 changes.
- Freetype used to be a dependency for MuseScore. Now Freetype code is in MuseScore repository.
- DPI is now fixed at 72
Why this changes? Over the last 3 year we have seen several reports of inconsistent rendering of scores on different OSes. We tried to fix this in MuseScore 2.0.2 by using Freetype directly and not relying on Qt to get glyph metrics. It did solve the cases we had at hand at that time. Unfortunately, we got more reports so the bug was not fixed. A week ago, we got a very good case showing a different layout between Linux and Windows/MacOSX. Werner took a closer look and find out that glyph metrics given by Freetype were different on Mac and Linux and it was due to the fact we were using a different version of Freetype on each platform. To solve this issue, the latest version of Freetype is now in MuseScore repository and compiled into the MuseScore binary.
Despite this change, the problem remains. After further investigation, Werner found out that layout computation were dependent on the DPI and the DPI was different from OS to OS. So he made the DPI a constant. Now all internal computation should be the same and independent of the OS. Since the screen DPI is different on each platform, the score is scaled after layout before being displayed on screen.
Comments
I'm almost at the edge of understanding this, but unfortunately not quite. I thought that DPI (or PPI) was dependent on hardware, not OS (though the OS may provide settings to override the monitor's scaling). Or is this something entirely unrelated to what percentage of actual size the score is displayed at?
There is physical DPI and there are a number of different "logical" DPI values. Consider, your monitor or graphics driver normally lets you change rsolution, but of course physically it's the same monitor. So I assume the DPI value being fixed is a "logical" one that you can basically just set in software.
Anyhow, since the change, I see a number of strange effects - score zoom factors being off, palettes drawing at different sizes from each other, inability to scroll all the way to the edge of a score. I'm guessing this is due to my use of the "-x" option I added to scale the GUI for my high resolution display, and I'm going to need to go in and revisit the scaling code to get it working again.
So my questions: do things sems to be working normally for everyone else, and is Werner basically done with he is doing or should I wait to inevstigate further?
In reply to There is physical DPI and by Marc Sabatella
The first thing I've noticed is the initial score is scaled down (to about 78%), even thought the scale display says 100%. Selecting the arrow beside scale% value (in the toolbar) to change it makes the score re-adjust to 100%.
Which palettes are you seeing differences in because I'm not noticing anything.
In reply to The first thing I've noticed by schepers
Yes! I just confirmed this, which means that this change has had real effects and (if you're on Windows) behavior is consistent across platforms, and https://musescore.org/en/node/74546 is now moot. The difference between the new 100% (achieved after clicking there in the toolbar), displaying the page as 8.5" wide, and the old "100%", with the score as 5.375" wide, is radical:
In reply to The first thing I've noticed by Isaac Weiss
I see a scaling of exactly 75%. My MScore::DPI was set to 96 previously.
In reply to There is physical DPI and by Marc Sabatella
I noticed some regressions and will fix them as i see. I guess changing the semantic of ScoreView->mag() was a bad idea. mag() is now relative to the internal fixed DPI value whereas the new pmag() is the real scale for the screen.
In reply to I noticed some regressions by [DELETED] 3
The change this morning fixed some of what I was seeing. But I still see the score jump in size when I first try to activate the zoom control. That is, when I first start up (without any "-x" option), the zoom claims to be 100% but "My First Score" displays tiny. As soon as I touch the zoom control - even without actually changing the value - the score increase in size to what appears to be exactly the correct size. This is different from 2.0.2, which would display 100% as too small unless I used "-x", so in that sense the new behavior is a marked improvement. But I am not sure why the score initially shows too small.
Also, the palettes still display too small on my high resolution display unless I use the "-x" option. Same for the web view in the Start Center, also the example views in the time signature properties and master palette windows, etc. If I run with "-x 1.5", the palettes look fine, as does the web view, but the example view in the master palette & time signature properties are still too small. So somehow, the "-x" scaling code is working as expected for palettes and web view but not for example view. I can certainl look into fixing that, I wonder if it would now be possible to alter the scaling code I added for the "-x" option to get the correct value automatically now without needing to specify "-x"?
Finally, if I run with "-x 1.5", then I still get the size jump in the score view when I first touch the zoom control - but now it jumps from too small to too big instead of from too small to just right. So I guess we need to back out the "-x" code from the score view and apply it to just the palettes, web view, and example view (and hopefully get the right value automtically rather than need a command line option).
My findings after the recent freetype-related changes (under Linux Mint 17.2, self-compiled):
The same happens vertically, as the page scroll up and down less than before; on a single page height, this hardly makes a difference in usability, but presumably in a vertical view mode across several page heights it would.
In summary, it looks like the programme thinks pages are smaller than they actually are.
For the rest, I didn't notice other adverse effects, but I am available to test other aspects which may show up later.
EDIT: regarding "fixing" the zoom factor: at least in my system, in no way pestering with the zoom factor combo box "fixes" to the same zoom factor as before: clicking the down arrow, clicking the "100%" item, even selecting a different zoom and going back to "100%": everything leads to the same smaller-than-before zoom factor.
In reply to My findings after the recent by Miwarre
My understanding is that at 100% the score should now be exactly like on paper (assuming Qt is able to give use the physical DPI of the screen correctly). So if you put a A4 sheet on your screen and MuseScore is displaying an A4 score at 100%, we should have a perfect match.
In reply to My understanding is that at by [DELETED] 5
I do see a perfect match to Letter size, but even after compiling in the latest scaling regression fixes I still have to click on the arrow beside the scale% value to get the display to re-adjust to 100%. I don't have to type any numbers, just click on the arrow.
I've determined the default scale I'm seeing the display/score start at is ~76.5%
Windows 10, 64bit.
In reply to I do see a perfect match to by schepers
@schepers, could you give exact steps to reproduce? In edit > Preferences > Score, what's the value of the default zoom?
In reply to @schepers, could you give by [DELETED] 5
There's no special steps, as Marc will likely attest to because he's seeing the same thing.
* Launch nightly, doing a factory reset to be sure.
* Close the Start Center and My First Score is visible, but shrunk.
* Zoom level says 100%
* Click on the down-arrow beside the 100% zoom and the score will resize.
I'm not on the PC with the latest nightly fixes but the default zoom, after a factor reset, should be 100%. Also, I'm not running MS with the -x option, it's all default. But I have two screens, Windows 10 64bit.
In reply to There's no special steps, as by schepers
Same here on OS X El Capitan.
In reply to Same here on OS X El Capitan. by Isaac Weiss
Ditto here (Windows 7 and 8.1): "The zoom claims to be 100% but "My First Score" displays tiny" , very tiny :(
In reply to Ditto here (Windows 7 and by cadiz1
I'm wondering if those that are reporting an incorrect score scaling on first start also have different native DPI from 96? Mine, I think if I've read the registry correctly, is 96, and 72/96 is 75%. My initial score scaling seems to be ~75%. Those that have much higher DPI would have fractions smaller than 72/96 and so the initial score would be even smaller.
In reply to I'm wondering if those that by schepers
My native DPI is around 166, so yes, for me, what you say could well be the case (I assume you mean, how different the native resolution is from 72). When I first start MuseScore, the default zoom is 100% and My First Score is supposed to be 8.5" wide, but it actually appears around 3.6" wide, regardless of any "-x" option. 8.5 / 3.6 = 2.36, and 166 / 72 = 2.31.
BTW, if you *really* want to know the native DPI, you don't rely on what the OS tells you. Just take the physical number of pixels your screen has and divide by its physical size in inches. My screen resolution is 1920x1080, and the screen is physically about 11.5"x6.5". Divide 1920 by 11.5 or 1080 by 6.5 and you get around 166. 96 is a much more common value.
I'm sure the OS might report different numbers depending on, for instance, whether you have deliberately set your display resolution to something other than native.
In reply to My native DPI is around 166, by Marc Sabatella
It's the close-but-not-quite-right that I can't figure out. I calculate 75% (72/96), but from my screen measurements the scaling I'm seeing is very close to 76.5%, yours has a similar error skew.
My DPI is 96 as I have a 24" panel, 1920x1200. I can't find any control panel or setting where Windows 10 tells you the DPI it thinks the display is using, hence the registry. WMIC can find it but I don't recall the location.
In reply to There's no special steps, as by schepers
Thank you !
I filed a bug #88066: When opening MuseScore the zoom level is not correct
In reply to Thank you ! I filed a bug by [DELETED] 5
The fix works great for me, thanks!
Since the score is now scaled correctly for me even without the "-x 1.5" I had been using, I would now love to get the palettes and example views to scale automatically as well. Do they look small to others with high DPI displays?
In reply to The fix works great for me, by Marc Sabatella
Further information: on my system, I can get almost everything to look good on my system with no need for "-x" if I make the following changes:
1) don't multply _physicalDotsPerInch by guiScaling in MuseScore::MuseScore()
2) instead (in that same place), set guiScaling to _physicalDotsPerInch / 96 if it wasn't set to something else on the command line
I think the number 96 is appropriate; it's basically the assumed DPI for the various hard-coded pixel dimensions we normally depending on (for icon & window sizes, etc). So the change I described should yield essentially no change on systems with "standard" resolution monitors. To be safe, I could add a fudge factor and keep guiScaling at 1.0 unless _physicalDotsPerInch is "significantly" different from 96.
But there is one thing that still doesn't look right on my system if I make the change I described, and that is the example view (eg, the display of the eighth notes in the time signature properties). These are not scaled, and hence look tiny. I *think* it is because the scaling that is done for the score itself happens in ScoreView rather than in the parent class MuseScoreView. We would either need to move the scaling to MuseScoreView so it could be inherited by ExampleView, or duplicate the scaling code in ExampleView.
I don't totally understand how the scaling code is functioning, and since it apparently doesn't work right on some systems or for non-default values of default zoom, I am reluctant to mess with that myself.
In reply to Further information: on my by Marc Sabatella
Can people following this post a screenshot of the Time Signature Properties dialog on their system as things stand with the nightly builds? From what I can see in the code, I am wondering if maybe it is *not* just high resolution displays where things are not correct. That is, I am kind of suspecting there might be issues on *any* system.
EDIT: Hmm, maybe never mind - I think I understand better and believe it probably looks fine on standard resolution displays. And I think I have a fix for high DPI as well, hopefully I will submit PR soon. But I'd still love to hear confirmation from others with high DPI displays that things do not look good for them right now. I can easily imagine Mac "retina" displays might look OK, but not on Windows?
In reply to My understanding is that at by [DELETED] 5
Well, the new version (even before the latest regression fixes) is actually 'right': a A4 sheet on screen is as large as a physical A4 sheet is (within 1mm of tolerance, which is pretty small, I believe); ver. 2.0.2 was 'wrong', as it displayed everything scaled up by approx. 11%.
With the latest fixes, even the scrolling limitations are gone, so everything I could try seems to work correctly.
In reply to My understanding is that at by [DELETED] 5
On my Desktop PC I'd need to use a zoom level of 138,5% for to have an A4 score on screen to be as wide as an A4 paper. No high-res/dpi screen, just ~96 DPI, 20", 1600x1200. Windows 7, latest commit from master, 067b5af
On my Laptop though I'd need to go up to 183% to have the same A4 score be as wide as a real A4 page, 1600x900 on a ~14" Screen, makes up for some 130 DPI I guess?
I'm now having unpredictable results when zooming by holding down [Cmd] and scrolling up and down. Pinch/spread still works normally.
In reply to I'm now having unpredictable by Isaac Weiss
Not unpredictable for me. It only zooms in, and at a much faster rate than 2.02.
Also, now it zooms by 45% each mouse scroll click, 2.02 zoomed by ~10% each click.
In reply to Not unpredictable for me. It by schepers
It's predictable that it will start by rapidly zooming in all the way (regardless of whether you scroll up or down), but when attempting to decrease zoom the behavior is fairly unpredictable—randomly jumping in and out as you scroll.
In reply to It's predictable that it will by Isaac Weiss
Well, no difference here with: 648340f
![composer.jpg]( "composer.jpg")
![120.jpg]( "120.jpg")
When opening, the zoom level displays 100%, and I receive about 60% (see image below: the right corner of "My First Score" is placed juste in front the double "bb" of the toolbar)
Other: if I choose in Edit/ Preferences/Score, a new value eg 120%, I get, after save-reload, a weird value in the zoom spinbox of 119,97%
In reply to Well, no difference here by cadiz1
1) I confirm the result of the previous comment with Windows7
2) But, with the same nightly: 648340f, and with a laptop (under Windows 8.1), I observe something else.
At the opening (always after a "RevertToFactorySettings"), the zoom level is correct, as expected.
But if I change the zoom value in Edit/Preferences/Score, eg 120% always, I get after save-reload an unexpected result, with a zoom level of 85.572%
Surprising. I can not say anything else.
In reply to 1) I confirm the result of by cadiz1
Confirmed about the difference between zoom level in preferences and resulting zoom.
Setting - Resulting Zoom
100% - 100%
120% - 90.8438%
140% - 105.984%
160% - 121.125%
In reply to 1) I confirm the result of by cadiz1
Well, some good progress here, but not yet returned to normal with this nightly: 010918b
1) On the laptop (Windows 8.1), it seems works well now: at the opening, "My First Score" is, as before, at the right size, and the change in preferences is as expected (if I choose 120%, the same value is displayed and not 85.572% as before)
2) However, on my desktop computer (Windows 7), the problem is half solved. The change in preferences is stabilized (if I choose120%, I get exactly the same zoom value, not 119.97% as before), but alas, at the opening, the size of my "My First Score" is still deficient (around 60%, as described above, with the right corner of the score in front of the double flat in the toolbar) while the zoom level showed is 100%.
In reply to Well, some good progress by cadiz1
So on your desktop computer, if you *don't* alter the preferences - actually, to be safe, run with "-F" to revert to factory settings - is the size of My First Score correct?
What is the actual resolution (in DPI) of your display? If you don't know that number, do you know physical size of the screen and the resolution in pixels? For example, if you have a 17" display, the dimensions might be 15"x8", and your screen resolution might be 1920x1080 pixels. 1920/15 = 128, so th.e actual resolution is 128 DPI.
In reply to So on your desktop computer, by Marc Sabatella
Of course, I always do the procedure "RevertToFactorySettings" (this is my daily bread!)
I have re-re-tried, and the size at the opening of "My first score" is always bad. Here's what I see (image below, click on it to see entirely)
I have a 22 "display, the dimensions are 18" x10 ", and my screen resolution is 1920x1080 pixels.
So: 1920/18 = the actual resolution is about 106 DPI, right?
In reply to Of course, I always do the by cadiz1
I'm curious! If you run a Command Shell in Windows, what does
wmic desktopmonitor get /value
return for the PixelsPerXLogicalInch and PixelsPerYLogicalInch?
In reply to Of course, I always do the by cadiz1
Interestingly, that looks very comparable to what it looked like on OS X before any of these changes: https://musescore.org/sites/musescore.org/files/old%20100.png
In reply to Of course, I always do the by cadiz1
For the record, I just tried with another desktop computer (always under Windows7) that I use rather for the home studio.
The screen is not the same as my main desktop computer: in this case, it is a 20 ", dimensions of 17" X 9/10", and a resolution of 1600 X 900. So, with a DPI about 94.
Result: wrong, with strictly the same deficient display of "My First Score"
So, I conclude that the size and characteristics of the screens are not involved here, but rather Windows7 ?
In reply to For the record, I just tried by cadiz1
I believe you are correct. If you run from a terminal window using the "-d" option, you should see some output that includes logical & physical DPI figures. I suspect you will see that physical DPI is being reported by Qt as 72 DPI on Windows 7 regardless of what the actual DPI of your monitor is, which is a real shame, Hopefully we can find a way to get a better value. For now I have proposed we simply assume 96 DPI on Windows 7, which is a lot more likely to be accurate than 72.
In reply to I believe you are correct. by Marc Sabatella
A windows release build will not display anything on the command line unfortunately. Only debug builds do so. They actually start another cmd dialog.
In reply to For the record, I just tried by cadiz1
Yep! Seems good again under Windows7. Phew...-;) And thanks!
In reply to Yep! Seems good again under by cadiz1
You're welcome :-).
I still expect people with Windows 7 (or older) who have high DPI displays (>96 DPI) will have incorrect scaling. But I also suspect this would have been true in previous releases as well - eg, 2.0.2, 1.3, etc. Can someone with a high DPI display who is running Windows 7 or older confirm or deny? That is, if you view a score at "100%" in 2.0.2, does it display the actual size it will print, or is it smaller? I'm guessing the latter, and that this will remain true in the nightlies. If 2.0.2 was somehow getting this scaling right for high DPI monitors on Windows 7 - which I rather doubt - then there is still a regression in this case that i don't know to fix yet. But if it was the same in 2.0.2, I don't think I will worry about it.
In reply to You're welcome :-). I still by Marc Sabatella
That indeed is the case, so no regression, but not really and fully fixed either. And apparently not fixable, so nothing to worry about.
In reply to That indeed is the case, so by Jojo-Schmitz
I agree with "nothing to worry about". The concept of appearing smaller on the screen than it appears in a printout is all relative to the page size anyway. Yes, the entire page appears smaller on the screen than it did in earlier versions of MuseScore, but I can always zoom in if I want it to appear larger on the screen. The printout is unaffected.
In reply to You're welcome :-). I still by Marc Sabatella
Hmm, the above two responses seem in conflcit. Jojo, it seems you are syaing you have a Windows 7 computer with a high DPI display and the score displayed on screen smaller than in the print in 2.0.2, and this remains true in the nightly, so there is no regression. But sideways seems to be saying the score appears smaller on screen than in previous versions, which sounds like there *is* a regression. Is that a Windows 7 syste, with a high DPI display? Are you saying that in 2.0.2, the on-screen display was correct - the same as the print - but in the current nightly (as of a few hours ago, with my fix applied), it is no longer correct? If so, then it *is* something I need to look at further.
In general, *other* than people using high DPI displays on obsolete versions of Windows, the on-screne display *should* pretty much exactly the same size as the print. That is one of the points of the changes made here.
In reply to Hmm, the above two responses by Marc Sabatella
not really super high res, some 120dpi, and a page at 100% is not as big on screen as in print. But it is the same size now, after the PR, as it is in 2.0.2. was quite a bit smaller before. On a 'normal res' Screen a score at 100% is almost the same size as in print now (and in 2.0.2)
In reply to Hmm, the above two responses by Marc Sabatella
No, seriously, nothing to worry about. It was a poor choice of words on my part. The nightly build looks larger than previous nightly builds with the 72dpi change, and much more similar to 2.0.2. My (poorly conceived) intention was to voice my feeling that the precision of this 100% concept is unimportant, because you know what size the paper is, and everything is relative to that - that even though the size on the screen might not match the size in the printed page it really isn't an important issue (for me). I chimed in without fully grasping the details of the conversation context within the topic.
In reply to Hmm, the above two responses by Marc Sabatella
OK, thanks for the clarifications.
I'd still love to find a way to get the physical DPI value on Windows 7, which is what we'd need to completely get this working as intended in all cases. But if it only fails for people with fancy new high displays but running ancient versions of Windows, and it fails no worse than 2.0.2, that's good enough for now.
In reply to OK, thanks for the by Marc Sabatella
Ah, I see a difference. I was focused this afternoon on the size of the score ("My First Score", but on returning tonight, I note that the toolbar has changed size now: the symbols are larger (well, not necessarily a disadvantage), see eg the printer icon, or the quarter note. But in return, the definition / resolution seems lower quality
(Click on the images below to see the difference.)
![ms2.jpg]( "ms2.jpg")
![4 janvier.jpg]( "4 janvier.jpg")
2.0.2 toolbar:
Last nightly:
In reply to Ah, I see a difference. I was by cadiz1
I am not sure what the intended effect on icons should be. I could imagine that maybe we are *trying* to make the icons be the same physical size on all systems regardless of display resolution or size. I have no idea if we are closer or further from this goal now, however. Maybe someone with access to a bunch of different systems could compare?
In reply to I am not sure what the by Marc Sabatella
Same result on my other computer (under Windows7) ie the icons of the toolbar have now a largest size, with as consequence a slight lost of definition (always, click on the images below)
EDIT: rather that the icons themselves (?) , the physical size of the toolbar is higher.
Ie, the height is: 3.1cm (1.2 in) with the 2.0.2, and now, 3.4 cm (1.3 in.)
(you notice also that the width of the score -"My First Score" - is different. On the second computer (same personal default zoom level to 120%), it touches the Inspector panel. Not with the main computer. But the yesterday update did not affect this)
So, with main computer: 22"display, dimensions 18" x10 ", screen resolution of 1920x1080 pixels/ 106 DPI, I receive:
![20 first computer.jpg]()
![nigthly first computer.jpg]()
- 2.0.2
- last nightly e842ec0
- With second computer: 20" display, dimensions 17" X 9/10", screen resolution of 1600 X 900 / 94 DPI, I obtain:
- 2.0.2
![2 0 second computer.jpg]( "2 0 second computer.jpg")
- last nightly
![nigthly second computer.jpg]( "nigthly second computer.jpg")
In reply to Same result on my other by cadiz1
If the monitors are different sizes or different resolutions, then the main MuseScore window might also be a different size from one computer to the next. So it is perfectly normal that the same size score would touch the Inspector in a narrower window but not touch it in a wider one. What matters is that the actualy physical size of the score on screen should be the same as when printed, and thus it should be the same size on every computer regardless.
I believe the same is true for icons - they should be the same physical size on each system - but I am not as sure about that.
In any case, screenshots don't really help, because they don't tell me the actual physical sizes of anything. You'd meed to get out a ruler and measure right there on your sscreen - are the scores and icons the same sizes on each system or are they not?
In reply to If the monitors are different by Marc Sabatella
AFAIK, being a Windows user/developer for many years, icons are fixed sizes in pixels, and thus vary in physical size depending on the screen resolution. If you are creating icons using bitmaps, they should scale along with everything else, not be fixed in physical size. Unless there is some scheme in Qt/C++ to manage a fixed physical size, but that would be outside of normal Windows behavior.
Printing a document to a physical page is an entirely separate conceptual space than program icons, and they do NOT operate the same way. Think of it this way: When you scale the view of the document to zoom in or out, do your program icons change size too? No.
In reply to AFAIK, being a Windows by sideways
Yes, unfrotunately, in the old days, icons were often a fixed pixel size, which worked as long as most monitors had similar resolutions. But with the advent of high DPI displays - 300 DPI or more rather than 72 or 96 - this became unviable. Icons started looking nusable tiny on high DPI displays. So each OS came up with a different scheme for trying to manage this, and applicatins have to try to sort throgh these different schemes to work reasonably on all the different OS's and different display resolutions. That is the point of many of these changes lately.
Anyhow, I don't know if having the same physical icon size on all systems is the best approach, but certainly just keeping a constant pixel size is not considered good practice any more, now that high DPI displays are becoming more common.
In reply to Yes, unfrotunately, in the by Marc Sabatella
Yes, and that points out my recent time away from developing: the past 7 years. And the last 7 years of that I was deep into programming MS Excel and Oracle Essbase, deep in the corporate world and deep in bizarre software legacy. Though for financial analysis, that stuff still rocks.
Anyway, once again I apologize for my lack of currency, and thanks for the polite lesson.
Still, conceptually and operationally, the document zoom size is entirely separate from the scaling of these icons, isn't it? On the one hand the changes discussed in this thread are about approximating the physical size of the printed page on the screen. On the other hand there is a separate OS mechanism/standard/idon'tknowwhat that handles generalized scaling of program icons. Or am I missing something there too.
In reply to Yes, and that points out my by sideways
Document zoom clearly has a "right" answer: 100% should mean, the same size as the printed page. It's not the end of the world if we don't achieve that result since you can zoom in as necessary, but it's clearly the most desired result.
For icon sizes, it is less clear to me what the right answer is. Simply using raw pixel dimensions is *definitely* not good. As mentioned, it leads to icons being way too small and hard to use on high DPI displays, which is why I implemented the "-x" option to scale the parts of the GUI that were relying on raw pixel dimensions. On the other hand, it's not a given that I always want the icons the exact same size either. That might depend on the physical size of my monitor. I might be OK with larger icons on a larger monitor, but prefer smaller ones on a smaller monitor so they all fit on screen at once. But my sense is, that is why we provide options to control icon sizes in Edit / Preferences. So I do kind of expect that a given setting for icon size should produce the same physical icon size regardless of monitor configuration. Just as I would hope a 12 point font is always the same physical size type size regardless of monitor configuration, and this is what OS and application support for high DPI displays usually tries to shoot for. But the reality is, often you have to deliberately play games with this since few OS's or applications deal with it as well as one would hope.
In reply to Well, no difference here by cadiz1
The discrepancy in the handling of non-default initial magnifications is easy to handle, I think: we need to scale the value of the local variable "mag" by physicalDotsPerInch() / DPI in ScoreView constructor, before using it to initialize _matrix. At least, that fixes the issue on my system.
In reply to It's predictable that it will by Isaac Weiss
The zoom behavior with mouse wheel is fixed for me by calling lmag() instead of mag() in ScoreView::zoomStep().
Something that I noticed while testing this: the step value for Ctrl+- and Ctrl++ seems really big. This isn't changed from 2.0.2, I just never really though it before. It's a factor of 1.7 as per incMag() and decMag(). Which is to say, Ctrl++ takes you directly from 100% to 170%, and Ctrl+- takes you from 100% to ~59%. Does anyone else think these should be finer steps?
In reply to The zoom behavior with mouse by Marc Sabatella
"Which is to say, Ctrl++ takes you directly from 100% to 170%, and Ctrl+- takes you from 100% to ~59%. Does anyone else think these should be finer steps?"
Yes, I would say that this should be the same increments at the scroll wheel or close. Does your new PR fix this as well?
In reply to "Which is to say, Ctrl++ by schepers
Now, I elected not to change this, since it's not a regression. It's easy to make that change, but maybe there should be separate discussion about that.
In reply to I'm now having unpredictable by Isaac Weiss
I've submitted a PR for the two regressions mentioned here: initial zoom set in preferences misintepreted, and bad scaling of zoom via mouse wheel. I *think* my changes should be good on any system, but I can prove it. Anyone capable of building from source, feel free to test:
https://github.com/musescore/MuseScore/pull/2293
In reply to I've submitted a PR for the by Marc Sabatella
I've submitted a separate PR to perform automatic GUI scaling - basically, it does exactly what "-x" does but sets the correct value by default (you can still override it with "-x"). This works nicely for me on my high DPI display on Ubuntu. It should also work for high DPI displays on Windows, and should not break anything about standard resolution displays on any OS. Only question is what it does for high DPI ("Retina") displays on Mac OS, so I welcome testing:
https://github.com/musescore/MuseScore/pull/2296
My guess is we will want to disable this code for Mac, since I think the OS does its own scaling.
I have found two issues that affect the "spatium" scaling factor in scores/files and I want to make sure they aren't affecting the testing being done on this new feature Both issues pre-date this 72dpi code and continue on after the 72dpi change. The most significant of these happens when you switch between mm and inch in the Page Settings. It seems to be a rounding error that is applied each time you switch. So if you happen to switch back and forth several times, the spatium gets progressively worse. And that spatium value is saved with the file.
So if you are viewing an older file with a wacked-out spatium in the 72dpi MuseScore, will there be side effects that were always there, but weren't visible prior to the 72dpi change? It's all scaling factors, multipliers, so there may be no problem at all. But people are looking up-close and in detail at their screens, and there seem to be a bunch of interacting changes made in the code, so I want to bring this up and check it out.
Just as a side note I think this will still not fix issues with different text hinting on different systems (https://musescore.org/en/node/82021), so score with lyrics will still have platform dependent line breaks (e.g.)