QT scale factor for skins

Continuing the discussion from Simple Layout for Old Timers:
There is described how to change the scale factor of skins.
For windows systems eg with :
set QT_AUTO_SCREEN_SCALE_FACTOR=0
set QT_SCALE_FACTOR=1.4
C:\\Program Files\\Mixxx\\Mixxx.exe

When I do that, there is an unwanted effect with the waveform display.
The waveform display field has reduced width when increasing the scale factor.
This is the display with scale 100%

and this is 110%, the running waveform is only the half size

with higher scale factors it is getting worse, at 150% there is no more waveform to see

the same effect is to see with stacked waveforms

The good thing is, I found a simple solution:
changing the skin solves it immediately, even if you change back to the first skin everything looks normal.
I tested it with Deere and Tango, same start behaviour and same solution.

Another strange thing happens when I try to use rotating knobs with the mouse, only with modified scale factor,
Pressing the left mouse button on rotating knobs moves the mouse pointer to the right for about 4 cm (on my screen).
This happens on all rotating knobs, master, balance, effects …
The right mouse button works fine.

Mysterious, I hope it is not Corona :skull_and_crossbones:

Reiterating to make sure I got it right:

  • When you start Mixxx after the scaling commands you would get the smaller waveform
  • when you reload the skin via Preferences > Interface the waveform display expands to full width of its parent container

Would you mind starting Mixxx with --developer argument? If you have tooltips enabled (also in Preferences > Interface) you get a lot of debug information when you hover over widgets with your mouse, for example the ObjectName and Size. I’d like to know the ObjectName of the blank area right next to the waveform.

Re: knobs
Interesting…! The issue was reported earlier but so far no one had any ideas hot debug that. The correlation with the Qt scale factor might help with that.

In general:
Please don’t mix up multiple issues, instead open separate topics here or bug reports on https://bugs.launchpad.net/mixxx/ that makes it easier to investigate each individually.

@ronso
you are right, this is exactly what happens
now I ran Mixxx with developer mode (very interesting feaature)
and made screenshots,
here is the left part of the waveform

and here is the right and empty part


when I move the mouse over the invisible “border” between them, the Info window disappears and will be reloaded

in the developer mode I have the option to reload the skin,
when I do that the waveform is displayed correct and I can move the mouse from the left to the right border without closing the Info window

I hope that describes the effects that I have clear enough.
Due to my very bad eyes I use very special screen configuration on my Windows system, increased size of fonts and apps and icons,
inverted coulors (white letters on dark background),
maybe these setting are causing this.

@ronso
sorry for mixing themes.
Just to make it sure :
The mouse - knob - jump thing is still there after reloading the skin.

okay, thanks.
how big is your screen? I’m puzzled by “when I move the mouse over the invisible border between them” since both the empty area and the visible waveform shot the same size…

Be warned that --developer mode is not suitable for live performance. It does output a lot of debug info and is demanding more CPU, so the latency is increased and you’ll get buffer underruns earlier.

@ronso
the desktop screen resolution is 1920*1200,
I think this screen is 24", but not sure, it is really large

The same size of the visible part and the empty part is only there with 110%,
when I increase the scale factor the visible part is getting smaller, see here:

right beneath the mouse pointer there is a thin white line, this is the border where the info window disappears.

I was not even thinking of using developer mode when playing live :beers:

@ronso
to make the confusion complete, I tested the same thing today on my Laptop, and what should I say,
no problem at all, everything works perfect from the beginning,
No reduced waveform display, no mouse jump on rotating knobs, tested with different scale factors and screen resolutions.
Maybe it has to do with the graphic adapter.
Both sytems are windows 10.

I can’t help any further, sry.
For the sake of completeness, please post the specs of both screens and graphics adpaters. Maybe someone can make sonething of it.

1 Like

I suspect this is an issue with the specific GPU driver. AFAIK this is first we have seen this problem and Qt’s scaling works fine for other Windows users.

Have you tried all the options for waveform renderer in the Waveforms preferences?

AFAIK this is first we have seen this problem

unfortunately, as linked above, we also have a bug report with the exact same symptoms

yes, the waveforms issue is probably caused by the graphics driver, but I can’t understand how the scaling / mouse pointer issue would be, too.

Hi ronso,
the graphics adapter of the problem-system is NVIDIA Quadro K620, the screen is DELL 2709.

The Laptop that I use for live is a Acer 17" with NVIDIA GeForce 840M, but there everything works ok.

@ronso
Hi , I found out something interesting concerning the waveform display and the mouse jump issue .
I have two screens here and normally start Mixxx on the second screen.
All this happens only when Mixxx is displayed on the second screen. Now I try to describe what happens:

1 - starting Mixx on primary screen
everything works well
2 - moving Mixxx from 1st to 2nd screen
waveforms correct, mouse jumps on left click
3 - moving Mixxx back to 1st screen
everything works well
4 - starting Mixx on second screen
waveforms are partially displayed and mouse jumps on left click
5 - moving Mixxx from 2nd to 1st screen
waveforms are partially displayed but mouse works fine
6 - reloading the skin
waveforms are correct on both screens , the mouse issue on 2nd screen is still there.

I must confess, to my shame, that all this has absolutely nothing to do with the usage of QT scale factor. I simply started Mixx always on the 2nd screen on my testing device.

I hope this will help to locate the problem,
for the moment the solution is as easy as:
do not run Mixxx on the second screen.