brunoherbelin / vimix

Live Video Mixer
GNU General Public License v3.0
283 stars 27 forks source link

autoadaptive interface for small screen but high resolution! #121

Closed MoorPoor closed 9 months ago

MoorPoor commented 10 months ago

Hei Bruno! special problem: very small screen but very high resolution! 2560x1600 @ 10"

I `m writing for a friend as his experience with vimix stopped more or less after opening the Programm, as he is not able to scale the menu right. I guided him once, but with time or update it changed again. For a new user, this is already a dramatic exclusion criterion :(

This is certainly a very special case, due to the extremely high screen resolution and very small display. a solution would still be helpful.

is there a way of somehow scale the interface according to the screen resolution? so that at least someone can see something and then adapt it to their own taste later?

he is using ubuntu 23.10 with 200% scaling screen setting but vimix seems to ignore this setting.

photo_2024-01-22_09-44-13

brunoherbelin commented 10 months ago

Thanks for the report !

It should adapt to the monitor resolution (this was tested with OSX retina screens).

vimix computes the base font size (before multiplying by scale factor) by obtaining the number of pixels in 4mm on the monitor, i.e. in effect on all monitors, the font height should be approx 4 milimeters.

float base_font_size =  float(Rendering::manager().mainWindow().pixelsforRealHeight(4.f))  ;
base_font_size = CLAMP( base_font_size, 8.f, 50.f);

with the following way to computer pixels in monitor using GLFW

int RenderingWindow::pixelsforRealHeight(float milimeters)
{
    GLFWmonitor *mo = monitor();

    int mm_w = 0;
    int mm_h = 0;
    glfwGetMonitorPhysicalSize(mo, &mm_w, &mm_h);

    float pixels = milimeters;
    if (mm_h > 0)
        pixels *= static_cast<float>(glfwGetVideoMode(mo)->height) / static_cast<float>(mm_h);
    else
        pixels *= 5; // something reasonnable if monitor's physical size is unknown

    return static_cast<int>( round(pixels) );
}

There are two possible causes for the problem;

So, before trying a bugfix, it could help to know a bit more. could you please give more info on the resolution / model of the monitor used?

brunoherbelin commented 10 months ago

And also to help with diagnostic, could I have the vimix logs after start (without any source loaded). It should look like;

0001  Refusing stream requests to vimix@Zephyrus.0. No streaming ongoing.
0002  Metronome Ableton Link Enabled
0003  Metronome Ableton Link start & stop sync Enabled
0004  Found the following hardware decoding gstreamer plugin(s):
0005  1. nvav1dec
0006  2. nvvp9dec
0007  3. nvvp9sldec
0008  4. nvvp8dec
0009  5. nvvp8sldec
0010  6. nvmpeg4videodec
0011  7. nvmpeg2videodec
0012  8. nvmpegvideodec
0013  9. nvh265dec
0014  10. nvh265sldec
0015  11. nvh264dec
0016  12. nvh264sldec
0017  13. vaapidecodebin
0018  Hardware decoding enabled.
0019  New session ready.
0020  OSC: Loaded 1 translation.
0021  OSC: Listening to UDP messages sent to 127.0.0.1:7000
0022  Stream 706034119373825974 Opened 'videotestsrc pattern=checkers-8 ! videobalance saturation=0 contrast=1 ! appsink name=sink' (6000 x 6000)
0023  Font size 25
0024   Session '' loaded with no source.

To get them, open Logs window Ctrl+L and clic the copy button

brunoherbelin commented 10 months ago

And I forgot to suggest the following temporary hack to help see something in vimix until the bug is fixed:

Open the file ~/.config/vimix/vimix.xml

Find the line setting the Application parameters;

<Application scale="1" accent_color="2" smooth_transition="true" save_snapshot="false" action_history_follow_view="false" show_tooptips="true" accept_connections="false" pannel_main_mode="0" pannel_playlist_mode="1" pannel_history_mode="0" pannel_always_visible="false" stream_protocol="0" broadcast_port="7070" loopback_camera="0" shm_socket_path="" accept_audio="false"/>

Change scale to a larger value, e.g. <Application scale="10"

MoorPoor commented 10 months ago

thanks for your response.

his resolution is 2560x1600 @ 10" but I would ask you to pause this issue for now, as he managed to adjust the scale factor and is happy for now. vimix and ubunut keeps the setting now, so no need to investigate further. Why it did not adjust well initially - I don`t know, but as this is such a special device and case, lets skip that as I have no access to that device.

sorry, for bothering you!

EDIT: Just a thought... maybe it has to do with the 200% scaling in the display settings of Ubuntu. I could imagine that this has no influence on the vimix interface? .... anyway

brunoherbelin commented 10 months ago

Okay, thanks for letting me know.

FYI, with this resolution on a 10 inches diagonal monitor, vimix would estimate the base font size at 47 pixels (for a 4mm height text). That is, if GLFW would provide the monitor size information. Therefore, as this is not the case, I conclude the problem is when GLFW cannot provide monitor size (i.e. here vimix sets font size to 20 pixels, i.e. ~1.5 mm font height, which could correspond to what your screenshot shows).

This shows that it can happen and vimix should have a way to prevent this. I will investigate for future versions.

brunoherbelin commented 10 months ago

I didn't find a general bugfix but increased the default font height and allowed larger scaling in Beta 5a077d2f52e65a29cc350e853be1aa662d3c1851

Hope it helps

brunoherbelin commented 9 months ago

Please try with Beta 47ff1a2dd8aea954e7de13838d91fc80f5bdc8df to launch vimix with command line and adding the argument --fontsize and a value:

vimix --fontsize 50

This will enforce a user-defined font size and should resolve this issue.