Roon will not display on 3200x1800 screen (says: screen to small)

I am currently in a trial period and Roon is looking very good on OS X and Windows10, however there is problem with screen resolution on Windows, quote “Your screen resolution is too small to run roon. Please try to run MAXIMIZED or FULL SCREEN”.

The screen is 3200x1800 on a Samsung 13.3" Ativ 9+, so it is anticipated that “too small” really means “out of range”, true?

Working with Java development, I have seen similar problems with high dpi resolution beyond 1920dp. There are serious scaling issue. (According to Oracle developers most likely caused by the underlying runtime system on Windows on which Java is running. Above 1920px, this system breaks apart, since it is simply too old in its design not anticipating higher DPI resolutions).

FULL SCREEN is working, but how to make Win10 accept windowed settings?

OS X works well. Android works, but the layout is not suited at the moment for smartphones (LG G2 and G3).

Hi Carl,

Check you have the latest drivers. If the issue continues then it may be that Windows 10 has increased desktop/font scaling beyond 125%. Are you using any scaling ?

The machine is constantly updated with the latest drivers. I use default Windows settings, but if you want me to check what scaling Windows has decided, please tell me how to investigate that.

I have verified that the Windows feature “disable scaling for higher dpi screen solutions” under “properties” for an application, makes no change.

This makes me think that you are perhaps developing Roon in a .net environment or similar, i.e., the setting for .net runtime is therefore overriding the setting I attempt to define for roon.exe.

Note: It does not help to reduce the resolution to 1920x1080.

Thanks Carl,

Let’s drop a flag for @mike to check out what’s up.

Same problem on my new Dell xps 13

OK, it can be good to elaborate a little for the developers to grasp the problem better, with a few examples:

  1. The app-start opening quote of Roon is very tiny, to the extent that the text is hard to read. I see how it is meant be on the Mac machine.

  2. MPC-HC is a tiny, tiny mediaplayer on this 3200x screen, i.e. shows same behaviour as the opening quote. Just a guess that this player and Roon is exploiting same or similar runtime environment with the “overruling” effects described above.

  3. Here is a link to the Java examples I made when suggesting the filing of a bug on the matter as it affects usability of all Java application, including their own Netbeans platform. It is obvious:
    Java non-compliance to high-DPI displays. The problem in Java can be manipulated by “operating” the java.exe and javaw.exe with e.g. the ResourceTuner app, and set the xml parameter dpiAware to false. Java apps will then allow to be subject to High DPI scaling by Windows as a (though blurred) remedy.

Roon not only looks at resolution, but also at DPI. What is your DPI setting?

In the Roon logs, there is a line in the first few lines that has something about “scale”… can you tell me that number?

For example, on a Macbook Retina, I see:

12/30 20:26:07 Trace: [brooengine] Window is running in scale 2
12/30 20:26:07 Trace: [brooengine] Using atlas scale 2

Can you tell me what yours says?

After restarting machine and Roon, using default 3200x resolution:

12/31 08:26:47 Trace: [brooengine] Window is running in scale 2.5
12/31 08:26:47 Trace: [brooengine] Using atlas scale 1

This is aligned the scaling used by Microsoft Edge (250%).

I found a Roon log from last night where it said scale 1.5, and it is likely that this is related to me switching from 3200 to 1920x resolution. (The only alternative resolution tried).

So the problem is that if you are running at scale 2.5, it doesn’t actually think you have 3200x1800 – you actually have 1280x720 as everything will be scaled up 2.5x. While 1280 is fine, 720 is too small (with a taskbar at the bottom, which is why fullscreen works).

So you have 3 choices here.

  1. Change your Windows scaling to 200% instead of 250%. That would probably make everything look better too since it’ll be a nice doubling of pixels and you will have a virtual resolution of 1600x900. (Apple gets this right by forcing 200% on their retina displays).

  2. You can run the Roon.exe with -scalefactor=2 which will force Roon to ignore the Windows settings and use 200%.

  3. Move your taskbar to the left or right, which should give you a full 720 tall.

1 Like

Thanks for these suggested intermediate remedies. My question remains unresolved. This problem thus seems somewhat complicated, so please allow for my further elaboration as follows:

Can someone please tell me how to run Roon with scalefactor=2? Or how to change windows scaling to 200%. I haven’t got a clue, and is it at all possible unless the application itself offers a scaling feature? I haven’t seen that.

Importantly, I would like to repeat that running in scale factor 1.5 (see above in this thread) did not remedy this problem.

Moving the Windows taskbar to one of the sides so as to allow for “720” was not effective.

There is a “brute force” feature to disable any Windows scaling, i.e. the “disable display scaling on high DPIs” under application properties, thus forcing Roon to run in 3200x1800 resolution. This does not solve the problem, but it can be noted that it has the consquence of moving the position of the startup quote from an “upper left” to a center position on the screen, i.e. there is a change in behaviour. I anticipate this is just a sign of most of the Roon GUI (except the quote and the misinterpretation of screen resolution) already being brought in compliance with the high DPI scaling machines?

To be strictly correct here, I am actually running not 1280x720, but actually 3200x1800, but when Windows scales (like a digital zoom) certain applications not yet tuned for higher dpi scaling, then this results in a 1280x720 quality, which is indeed a lousy and blurred quality on this computer. Hence, this is at best an intermediate remedy.

Important: Roon takes full advantage of the “native” 3200x1800 display resolution. It means the only problem with Roon at present is the incapacity for running in windowed mode on this computer.

Software applications are more and more emerging that are properly tuned to take advantage of the high dpi scaling. Examples are Microsoft Edge (even if it says it scales to 250% it has full granulation according to the computers display resolution) and Chrome.

For all the non-compliant apps, one remedy is to scale down the computer to 1920x1080, which is a “standard” quality as of 2016. This does not help for this Roon problem.

I have 3 days left of my trial, but the rest of Roon is excellent to the degree that this is not a showstopper.

For anyone with the same problem: My remedy is that I have learned to switch between “full screens”, like Roon, the desktop, etc. (Window button + tab).

I would start by looking at Control Panel > Appearance and Personalization > Display and selecting Make Text and other items larger or smaller – in Windows 8.1 it looks like this:

If that doesn’t work, you can force the scale factor like this:

The Roon exe is in the Application folder of your Roon folder

You can also can add the same -scalefactor=2 argument to the shortcut that you launch Roon with on your desktop or Start menu.

Let me know if that helps @Carl_Henrik_Janson!

1 Like

It does, but it obeys system DPI scaling rules. Since you have a scale factor of 250%, we emulate 720p, but your fonts will actually display smooth at full resolution. Roon does not let Windows do the scaling in the horrible way.

If you want to test this, just run with -scalefactor=1 to see your fonts become itsy bitsy. @mike has instructions on how to do that.

Thanks for the responses. Confirmative that Roon will run in windowed mode using -scalefactor=1 and that fonts become itsy bitsy. Switching to screen resolution 1920x and the limit scalefactor 1.25, Roon is bordering on being acceptable with respect to font sizes, i.e. a kind of “enlarged itsy bitsy”. It is not elegant, but readable, and with the benefit of enabling “windowed mode”.

I will wait for a new version of Roon that does not misinterpret screen size and resolution on Windows computers with higher dpi displays.

Note that it does not help to return to a size of 1920x screen resolution, 1920x being presently a kind of “default resolution” on a laptop, so this is likely a general problem on Windows.

Also note that most applications by now are compliant to higher dpi displays, including the windowing mode. This was not the case when this laptop was purchased 1.5 year ago. Chrome, now compliant, is one example here. IOW, it should be possible to find a solution.

If Roon developers would like me to do tests on this machine, just send me an email.

Roon is not misinterpreting the screen size and resolution here. We’ve spent quite a bit of time on this problem, testing on many machines and different DPI’s. We even provide assets and render fonts at higher resolutions, and we even do the right thing on Apple devices where the texture resolution is different than native screen resolution.

Windows, when asking for the current DPI, will return 96 to mean “native”, and it scales from there. Windows will lie to you and scale your app itself, unless you tell it that you are DPI aware. The fact that you see everything get very small when you do -scalefactor=1, shows that we are telling Windows that we are DPI aware and it should tell us the correct number, and not lie to us.

Now, there are 2 things to consider here when talking about resolution. We have what I call “real estate”, which is how much space in you have to put stuff when you measure with a ruler, and then you have resolution, which is how many pixels you have. My Roon footer should be the same size as your Roon footer. As we are DPI aware, if both our DPI settings were set correctly, that footer should be about 1 inch tall. Now, if your resolution was 768 tall, you’d have 768 / height-of-screen-in-inches pixels for that footer’s height. If your resolution was 1800 tall, you’d have 1800 / height-of-screen-in-inches for that footer’s height. Over twice the number of pixels in the 1800 case. So what do we do with all those extra pixels? The footer needs to be 1 inch tall in both cases, but in the cases with more pixels, we should draw more detail there. That means higher resolution artwork and higher resolution glyphs for the fonts being rendered. Each character and icon should take up about the same size in inches, but the higher resolution screen will look better.

Because your Windows scaling option is set to 250%, and your actual LCD is 3800x1800, your effective screen real estate is 3800/2.5 x 1800/2.5, or 1520 x 720, at “96 DPI”. If we were not telling Windows we were DPI aware, Windows would just scale us up and just lie to us that it was 1520x720. Instead, we are doing that same scaling behavior, but instead of doing a dumb scale, we are using the extra pixels with higher resolution graphics artwork and font rendering.

The end result however is the same for real estate, you have an effective desktop of 1520x720 and that’s what’s causing you to break. Long ago, before screens were high DPI, you would be hard pressed to find a 13" laptop with a resolution much higher than 1520x720. 1366x768 would have been common, slightly less 16:9 in aspect ratio. The benefit of having a small screen with a large resolution means you can control your effective real estate. For example, a 15" Mac 5 years ago would be 1440x900. Today, it is 2880x1800, but it is 200% scaled, so it is effectively the same thing it was 5 years ago. However, I lie to my Mac, and tell it that i don’t want 200%, but instead i want 150% scaling. That gives me real estate of 1920x1200. I get more real estate, at the cost of making everything a bit smaller. 5 years ago, to get 1920x1200, i would have to have a 17+ inch screen. Now I can make the tradeoff between size and resolution.

If you set your scaling to 200%, you’d get a scalefactor of 2x, which means 3800/2 x 1800/2 == 1900x900 – its a bit much for 13 inch display I think, but more than enough for Roon. Maybe 234% would work better? that would get you 1624x768 – which is similar to what you would have on a 13" before high DPI screens were available.

This stuff is really confusing, and I see manufacturers mess it up all the time. Apple totally nails this and the Android devices are mostly OK at this as well. Windows is a mess because the manufacturers really get their hands in there and mess up stuff. Putting a 3800x1800 screen on a 13" display is just stupid as you will always have either something too small, too big, or blurry.

I’m guessing you have a Samsung. They are famous for hyping up specs without considering what the consequences are. They do it on Android too.

1 Like

just re-read the original post… Samsung indeed.

Danny, your comprehensive response is very much appreciated. Indeed, yes, the “global pixel show” is quite a mess and discussions about it will increase competence and is all for the good. I can add some more:

The roon policy to develop a proprietary GUI handling, rather than leave it to Windows digital zooming producing embarrassing resolution qualities, is absolutely saluted. It seems roon have done much the same as has been developed on Android with the DIP technology (Device Independant Pixels). On Android, it means the problem is solved (I develop audio applications for Android).

With this ambition it becomes a question of going the last mile. One tiny quickwin on the way would be to change the error message “screen is too small…” to a less precise variant, for example "With the current screen resolution, roon can only run in full screen mode. See help. ".

One fully working example is MS Edge that can exploit in full the available screen resolution 3200x1800, while remaining in compliance with other features like running in Windowed mode. So there should be a way to fix this. I anticipate an application is able to request “physical screen resolution” in other words, that roon has the option to be “physical dpi aware” and can take it from there?

roon have decided as a policy that if the screen is not in compliance with roon display technology, the solution is full screen mode, while Windows runs by another policy in that it is possible to disable the default setting, i.e the blurred, “digital zooming” on higher dpi displays. In a situation with a lack of compliance, it could be a good thing to leave the decision to the user (if technically possible). I am unappriciative of the blurred Window lying too, but all things considered…

3200x1800 resolution on a 13.3 is nonsense in that context only, yes, but in principle, Samsung is not completely out of line here. I have a last model 65" Samsung TV to which I often miracast (or earlier: chromecast) the laptop screen. It is a swift one-click operation in Windows10 and quite impressing. While this laptop is still alive, it is not unlikely that the miracast developers will proudly announce 4k/UHD compliance, i.e. casting in a 4096x 2160 granularity. Current max is 1920x1080.

In that case, the high dpi screen could be more relevant as the user would seek to enjoy the full resolution on the TV used as a pc screen. As I understand this technology, the TV will follow the pc screen resolution to the extent possible, so the pc should be running 3200.

In the development of the cross-platform SoundPimp Audio Enhancer, we have the same problem as roon, because the GUI is in Java (and Android). The problem with Java is that the Java runtime exe files declare their dpi-awareness just like roon does, however Java breaks apart from 1920x1080 and upwards, creating very funny titsy bitsy layouts. If I “operate” the xml parts of java.exe and change to dpi-aware=false, then Windows blurred scaling is enabled.

So Oracle is the worst lier, but out of ignorance. After struggling half a year with getting attention inside Oracle, I finally wrote a personal letter to Larry and all Oracle board members and posed the leading question if they wanted Java to survive the emergence of higher DPI displays or not? That helped so it is now an officially unresolved Java bug and is likely to be solved in approx 2020.

In the context of “real estate”, I finally add that on a Macbook Air 2009, with a display resolution 1280x800, running El Capitan, the roon “playbar” footer is per default under the OS X docking, hence I had to set the dock to autohide. (Actually a better solution, for me).

I am very impressed with the otherwise flawless use of this Mac as a remote controller for the roon install on a Windows pc. Bravo!

I like that, we need to detect if fullscreen is enough (because it may not be), but if it is, we should make the error seem less critical.

The problem is what to do when you have enough pixels but your DPI settings make it so you can’t fit (even fullscreen). There is an option… we could cheat. For example, if we had automatically detected that 250% was too much, we could have dropped it until it was OK (just within Roon). We do this on Android Tablets when there are enough pixels, but the DPI setting would prevent us from having real estate. However, on Mac/Windows, that would require runtime DPI switching, and we don’t have that implemented yet. You can trigger this limitation when you move your Roon window between two monitors attached to the same computer, each having different DPIs. It’s on my todo list to fix!

1 Like

Hi all,
Very interesting discussion. Has this been resolved in the end? Just got a new Lenovo X1 and having the same problem.

Roon is very close to solving this problem. Their algorithm does not take into account the height of the taskbar when calculating, hence the “screen is too small” false message. That’s how close they are. Hope they fix it soon, it is an old bug and quite annoying because it hinders using roon in non-fullscreen mode. On my Samsung ativ 9+ with 3200x, this is no longer a problem. On another Samsung ativ 9 (not +), having 1920x, the problem persists.

If you are having this issue, you need to change your scaling. Resolution independently no long matters, only in the context of DPI.