Display Bug when using a projector (2.7.6)

[Bmute]

Hello

This is my first post here, so I'd like to express my appreciation for avidemux and thank the developers for their hard work. Even though I have no idea what most options mean, the program is still easy to use and the result is almost always great.

The bug: The resolution of my laptop screen is 1920x1080. I plug in a 1280x1024 monitor. 2.7.6 sticks to 1920x1080, so the interface is jumbled up and does not respond to clicks. I have 2.7.1, 2.7.2, 2.7.3 and they all still work fine. I mostly use 2.7.1 because it allows drag-and-drop for combining two videos.

[eumagga0x2a]

The bug: The resolution of my laptop screen is 1920x1080. I plug in a 1280x1024 monitor.

In which mode? As mirror? As the only display (built-in panel disabled)? As extended desktop?

2.7.6 sticks to 1920x1080, so the interface is jumbled up and does not respond to clicks.

Do you add the second screen on the fly?

I would expect Avidemux to be broken with multiple displays as this is completely untested.

I mostly use 2.7.1 because it allows drag-and-drop for combining two videos.

There was a bug with drag-and-drop, fixed a long time ago. Is something special needed to reproduce the issue?

[Bmute]

In which mode? As mirror? As the only display (built-in panel disabled)? As extended desktop?
Do you add the second screen on the fly?

The 1280x1024 external monitor is always plugged in (I start Windows with it). The laptop screen is always off. If I open the lid, my external monitor automatically switches off, laptop screen automatically switches on. 2.7.6 works normally on the laptop screen (1920x1080).

I use Win7 64bit. My installers are 64bit. The interface is only jumbled with maximized window. When not maximized, the interface is normal but the window is too large to see the interface. The program does not allow me to resize the window. Please see attached screenshots of what it looks like on my 1280x1024 monitor.

There was a bug with drag-and-drop, fixed a long time ago. Is something special needed to reproduce the issue?

According to your link this was fixed in 2.7.4 but I had only been up to 2.7.3!

I went ahead and downloaded 2.7.4 or 2.7.5. Both of them have the display bug. So something that came with 2.7.4 must have brought about the bug.

Should I keep using 2.7.1? I only cut and combine mkv/mp4/avi and leave the result as mkv (I want to keep the original quality and don't change any settings). I read the patch notes but don't understand much.

[eumagga0x2a]

Thank you.

Regarding Avidemux version, I can't imagine wanting to use anything older than the latest nightly build as I know what was broken before and works now. Of course, this is a skewed view of someone involved in the project.

There are two Avidemux 64bit flavors for Windows, Microsoft Visual Studio (VC++) builds (vsWin64) and MinGW builds (win64).

Please start Avidemux (the latest nightly only! --> https://avidemux.org/nightly/win64/), maximize the window on the 1280x1024 screen, close Avidemux, then compress and attach admlog.txt from %localappdata%\avidemux\

I tested appending videos with drag'n'drop and it worked for me reliably (well, on Windows 10, I'll recheck on Windows 7 later today or tomorrow). If it doesn't work for you with the latest nightly, please help me to reproduce the issue.

[eumagga0x2a]

Can it be that you've set DPI scaling to 120% or higher? This would trigger automatic HiDPI mode (scaling to 200%) in Qt toolkit, used for Avidemux graphical user interface.

To disable Qt autoscaling, create environment variable QT_AUTO_SCREEN_SCALE_FACTOR and set its value to 0. This will disable autoscaling for all Qt applications, however.

[Bmute]

I'm attaching both the win64 and vsWin64 log.

The drag-and-drop bug was fixed in 2.7.4, I only encoutered it using 2.7.3. 2.7.3 has a normal (not enlarged or jumbled) interface however.

Setting QT_AUTO_SCREEN_SCALE_FACTOR to 0 works for 2.7.7! Both win64 and vsWin64 now have a properly sized interface. Would you recommend the win64 or vsWin64 version?

[eumagga0x2a]

I'm attaching both the win64 and vsWin64 log.

Thanks. Indeed, Qt was applying HiDPI scaling:

Code Select Expand

The screen seems to be 640 x 481 px
[...]
[admD3D_initD3D9Ex] 13:05:48-033 Display is 1280 x 1024, fmt=0x16
You didn't comment on your DPI scaling settings, but it looks like cranking up the DPI value on a display which doesn't match the specified DPI as a way to force larger font sizes is a recipe for disaster.

The drag-and-drop bug was fixed in 2.7.4, I only encoutered it using 2.7.3.

Thank you for clarifying this, the subject made me think that the drag'n'drop problem persisted with 2.7.6.

2.7.3 has a normal (not enlarged or jumbled) interface however.

Sure, 2.7.3 didn't have the Qt autoscaling enabled, which means it was almost unusable in real HiDPI conditions by default, a grave issue considering proliferation of high resolution displays in laptops. The feature was also repeatedly demanded by users...

Setting QT_AUTO_SCREEN_SCALE_FACTOR to 0 works for 2.7.7!

As expected.

Would you recommend the win64 or vsWin64 version?

If you want to be able to load VapourSynth scripts in Avidemux, you can do it only in VC++ builds.

Apart from that, the choice hardly matters*. Both flavors don't require installation, they are fully portable applications. Always.

Two video filters – fluxSmooth and telecide – are not available in VC++ as is the SDL2 video renderer. That's all. But who in the world might need to use the latter? As long as graphics drivers are not completely borked, one would use the DXVA2 renderer (calling it "DirectX" would be more accurate), else the OpenGL one, else the unaccelerated "Qt" output as the last resort.

In this sense, from user perspective, I think that both are as good as equivalent. However, VC++ is beneficial from developer perspective as MinGW builds are not debuggable.

*) In the 2.7.6 release VC++ build, a small build environment issue (zlib had a wrong name) resulted in PNG support not compiled into the bundled libavcodec library. All later VC++ builds had this fixed.

[Bmute]

Thanks! I indeed have 150% DPI scaling because Microsoft likes everything to be tiny.