After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 615478 - Image doesnt scale for dual monitors
Image doesnt scale for dual monitors
Status: RESOLVED OBSOLETE
Product: gnome-desktop
Classification: Core
Component: Background
2.30.x
Other Linux
: High minor
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-11 20:51 UTC by theguns
Modified: 2018-09-21 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Git formatted patch from https://bugs.launchpad.net/ubuntu/+source/meta-gnome2/+bug/521492/comments/30 (909 bytes, patch)
2010-12-31 01:19 UTC, Florent Viard
none Details | Review

Description theguns 2010-04-11 20:51:21 UTC
Exactly the same problem as described in https://bugzilla.gnome.org/show_bug.cgi?id=603551 but for gnome 2.30.0 on UBUNTU

On 2.28.x there is no bug.


I use a dual monitor setup. Before the update I was able to scale the
background image.
eg. If the image is of resolution 3600x1200 and I have two monitors one on 1920x1200 the other one on 1680x1050 pixel
then the pic would appear to be spread across the two monitors. 

Now the same 3600x1200 image appears as *two different* images on both
monitors.

In GNOME 2.28 i used "Zoom" option to span the image across two monitors, now "Zoom" got different behavior and "Span" doesn't work too.

Thanks!
Comment 1 Romain Perier 2010-04-12 20:44:29 UTC
Same problem here, but also if the wallpaper is spanned with a 3360x1050 image (on a 2960x1050 display) the resulting background is only spanned on width and completed with color. (the background is not adjusted on height)

see yourself  http://img685.imageshack.us/i/screenuh.png/
Comment 2 Oybon 2010-05-29 13:06:49 UTC
Same here on ubuntu 10.4.

All but span is single screen, and span does not stretch the image to `span´ both screens correctly.
Comment 3 Paul Kishimoto 2010-06-25 21:26:40 UTC
The report at https://bugs.launchpad.net/bugs/521492 has 4 duplicates and is confirmed by 39+ users.
Comment 4 Gerry 2010-08-07 04:14:15 UTC
Confirmed on Ubuntu Lucid - Gnome 2.30.2

This regression happened on all types of wallpaper layout though, not just zoom. All effects now happen per monitor instead of per viewport.
Comment 5 Michele Mattioni 2010-11-03 10:50:28 UTC
I just want to give an hint so somebody else, more familiar with the code, could take a look:

consider this (mine) setup: 
screen 0: 1280x800 ; screen 1: 1280x1024
Using nvidia driver, mode twinview, option Clone.

With this option the big screen is the one with the normal resolution, and the smaller one is showing just the amount of pixels it got. In this scenario the smaller screen is not showing the bottom part, lacking 224 pixel to be precise.

I think the problem is due to the method which draw the image on the second screen, which is using the dimension of the first screen. That's why any choosen method, from scale to span to stretch to tile doesn't work.

The problem is before the transformation.

This is especially evident if the tile mode is used where the image starts from -800 pixel from the top (and not -1024 as it should be) and is than repeated for the other part.

Therefore my guess is: the method who takes the screen dimension is correct, the method that apply the mathematical transformation to the background image is using the (wrong) dimension of the 0 screen, but applying them on the area of the bigger screen.
Comment 6 Michele Mattioni 2010-11-03 10:51:18 UTC
(In reply to comment #5)
> I just want to give an hint so somebody else, more familiar with the code,
> could take a look:
> 
> consider this (mine) setup: 
> screen 0: 1280x800 ; screen 1: 1280x1024
> Using nvidia driver, mode twinview, option Clone.
> 
> With this option the big screen is the one with the normal resolution, and the
> smaller one is showing just the amount of pixels it got. In this scenario the
> smaller screen is not showing the bottom part, lacking 224 pixel to be precise.
> 
> I think the problem is due to the method which draw the image on the second
> screen, which is using the dimension of the first screen. That's why any
> choosen method, from scale to span to stretch to tile doesn't work.
> 
> The problem is before the transformation.
> 
> This is especially evident if the tile mode is used where the image starts from
> -800 pixel from the top (and not -1024 as it should be) and is than repeated
> for the other part.
> 
> Therefore my guess is: the method who takes the screen dimension is correct,
> the method that apply the mathematical transformation to the background image
> is using the (wrong) dimension of the 0 screen, but applying them on the area
> of the bigger screen.

Most probably the error is on this one:
http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-bg.c
Comment 9 Jeremy Nickurak 2011-03-04 16:20:20 UTC
Reportedly worked correctly on earlier versions. Regression.
Comment 10 Pontus Rodling 2011-07-31 17:16:55 UTC
Though this irritated me a lot, I realized that this is actually the logical behavior of Zoom.
Zoom used to span and zoom, while it really should just zoom per monitor, just like Center doesn't center between two screens, Span does that instead.

Instead of breaking any of them further, I patched my local gnome and added a new mode called "Span and zoom" which does what Zoom used to do. With this, all the modes have what at least I think are their logical behaviors. "Span" spans, "Zoom" zooms, "Span and zoom" spans and zooms.

The difference can be seen in these screenshots:
Span: http://static.frigolit.net/misc/gnome-bg/span.jpg
Zoom: http://static.frigolit.net/misc/gnome-bg/zoom.jpg
Span and zoom: http://static.frigolit.net/misc/gnome-bg/span-and-zoom.jpg

Hopefully you'll agree with me that this is the best solution, in which case I'll make and submit a patch using the latest sources.
Comment 11 GNOME Infrastructure Team 2018-09-21 16:30:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/32.