Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misaligned background tiling with multiple display resolutions #24

Closed
huntie opened this issue Feb 28, 2018 · 11 comments · Fixed by #25
Closed

Misaligned background tiling with multiple display resolutions #24

huntie opened this issue Feb 28, 2018 · 11 comments · Fixed by #25
Labels
awaiting feedback bug Something isn't working

Comments

@huntie
Copy link
Contributor

huntie commented Feb 28, 2018

I'm using a 13" 3840x2160 resolution laptop connected to two 1920x1080 external displays in the pictured arrangement, with one external display rotated vertically ("Portrait Right"). I am running vanilla GNOME under Ubuntu 17.10 and Wayland (which lets me slightly reduce the resolution of the built-in 4K display to fine-tune scaling).

screenshot from 2018-02-28 17-53-39

HydraPaper correctly lists all including the rotated display, but sadly creates a background wallpaper which is misaligned with the display regions and is disproportionately scaled.

screenshot from 2018-02-28 10-09-18

I may be able to make a start looking into this, and believe it is caused by the resolution differences rather than the single rotated display. Need to test under Xorg as well as with different monitor arrangements, but neither of these are optimal for my usage in this setup.

@GabMus
Copy link
Owner

GabMus commented Feb 28, 2018

This is kind of a known issue, I couldn't wrap my head around "detecting" when a setup is arranged vertically. I decided to forget about it since it's an uncommon setup, but I guess the time to work on it has finally come.

There is some math I have to figure out, follow this issue, I will be posting a test flatpak when I've got something.

@GabMus GabMus added the bug Something isn't working label Feb 28, 2018
@GabMus
Copy link
Owner

GabMus commented Feb 28, 2018

Should have added proper support for vertical setups hopefully (only tested with different positions of my 2 monitor setup).

Please try installing this and report back.

hydrapaper-1.2-17-g02c0711.zip

@huntie
Copy link
Contributor Author

huntie commented Mar 1, 2018

Thanks for the lightning-fast response and build, really appreciated!

Here's how it looks now, a significant improvement. Parts of the tiled image do reach all bounds of the arranged screens, however the images appear equally scaled, a little much for the external 1080p displays, and a little low for the internal 4K display. I've positioned one window centred on the lower 4K screen to illustrate the scaling difference.

screenshot from 2018-03-01 16-04-31

@GabMus
Copy link
Owner

GabMus commented Mar 1, 2018

Try setting a single image (possibly one where you can see its boundaries) as wallpaper through GNOME settings, then send a screenshot.

Also, go to ~/.var/app/org.gabmus.hydrapaper/cache/hydrapaper, order by last modified and send the most recent file in the folder (should be the last wallpaper you generated). This could help me with troubleshooting.

@huntie
Copy link
Contributor Author

huntie commented Mar 1, 2018

Here you go, these screenshots definitely shed light on the issue. Image starting positions correctly match the top left on all monitors, and it appears to solely be the scaling of the lower image that is misaligned now (GNOME resized the wallpaper HydraPaper created to fit in the above case, leading to the illusion of scaling and therefore alignment differences).

Full screenshot with single wallpaper: https://public.alexhunt.io/26c099a1-7209-41c4-8825-23cc35f1c696.png
Most recent generated HydraPaper image: https://public.alexhunt.io/62a797d1-f60d-44b7-bb82-c17690ccd5d7.png

I'd love to join in with fixing this, or tackling other issues on this project, so will see if I can set it up soon.

@GabMus
Copy link
Owner

GabMus commented Mar 1, 2018

You sent the same file twice :/

@huntie
Copy link
Contributor Author

huntie commented Mar 1, 2018

Sorry, amended.

GabMus added a commit that referenced this issue Mar 1, 2018
@GabMus
Copy link
Owner

GabMus commented Mar 1, 2018

According to the pictures you sent me the problem lies within scaling. The solution I want to come up with is weird, and I have two flatpaks I want you to try.

First try this one, refer to it as 20: hydrapaper-1.2-20-g3dc1e04.zip

This basically doubles every measure for each monitor that does NOT have scaling


If it still doesn't work properly, try this other one, refer to it as 19: hydrapaper-1.2-19-g0325489.zip

This doubles every measure for each monitor that does NOT have scaling, and halves every measure for each monitor that DOES have scaling.

Test everything and report back.

@huntie
Copy link
Contributor Author

huntie commented Mar 2, 2018

The two builds create an identical image: https://public.alexhunt.io/0aa82431-f3d3-4370-9d33-8deca3eb99a1.png Currently neither has scaled the lower image independently up to a 4K size, however the entire image is 6000px wide, so some scaling has occurred.

Going off the grid for the next week and won't have access to my monitor setup :| Massively appreciate all the work done so far, and I will clone this project and have a play when I'm back to help resolve this issue :)

@GabMus
Copy link
Owner

GabMus commented Mar 3, 2018

Weird, I thought I nailed it this time.

Anyway, thank you for your support. If you want to contribute, you should look at the multi_setup_pillow function inside /hydrapaper/wallpaper_merger.py. It's probably best if you do it yourself, since it's not easy to guess what would happen in a setup I don't have.

If you make any progress or need any help, feel free to comment here :)

@GabMus
Copy link
Owner

GabMus commented Mar 3, 2018

The two builds create an identical image

Are you sure tho? Between one build and the other you should delete every file in the cache, otherwise it's gonna make a hit and use a previously generated file instead. If you could try again like this it'd be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants