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 786120 - User's avatar does not get updated when the scaling-factor changes
User's avatar does not get updated when the scaling-factor changes
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-08-10 18:42 UTC by Mario Sánchez Prada
Modified: 2017-08-11 10:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Resize the user's avatar when scaling factor changes (2.05 KB, patch)
2017-08-10 18:44 UTC, Mario Sánchez Prada
none Details | Review
Resize the user's avatar when scaling factor changes (2.10 KB, patch)
2017-08-10 19:02 UTC, Mario Sánchez Prada
none Details | Review
Resize the user's avatar when scaling factor changes (1.59 KB, patch)
2017-08-11 08:45 UTC, Mario Sánchez Prada
accepted-commit_now Details | Review

Description Mario Sánchez Prada 2017-08-10 18:42:27 UTC
When switching from one resolution to another that implies getting the scaling-factor's value changed (e.g. moving from 1920x1080 to 3200x1800 on my 13" Yoga 900 laptop), the size of the user's avatar does not get updated accordingly.

This might not be a terrible issue on the upstream shell since the avatar is not as prominent as on Endless (where it's featured right on the bottom panel), but I think the fix is still relevant, so it would be nice to land it here as well.
Comment 1 Mario Sánchez Prada 2017-08-10 18:44:37 UTC
Created attachment 357353 [details] [review]
Resize the user's avatar when scaling factor changes
Comment 2 Florian Müllner 2017-08-10 19:00:15 UTC
Review of attachment 357353 [details] [review]:

::: js/ui/userWidget.js
@@ +57,3 @@
             this.actor.child = null;
             this.actor.style = 'background-image: url("%s");'.format(iconFile);
+            this.actor.set_size(this._iconSize * scaleFactor, this._iconSize * scaleFactor);

I think you should move this out of the if-block: The actor has an explicit size (in _init), so we shouldn't rely on it to adjust its size to a resized child in the else-block.

@@ +61,3 @@
             this.actor.style = null;
             this.actor.child = new St.Icon({ icon_name: 'avatar-default-symbolic',
+                                             icon_size: this._iconSize * scaleFactor });

This looks wrong: the icon-size property inside StIcon is considered unscaled, and the scale is applied when the icon texture is loaded. So I'm pretty sure you are double-scaling here.
Comment 3 Mario Sánchez Prada 2017-08-10 19:02:28 UTC
Created attachment 357354 [details] [review]
Resize the user's avatar when scaling factor changes

The previous patch considered the scaling factor when setting the size via StIcon's icon-size, which was not needed (it will be handled internally in st_icon_update())
Comment 4 Mario Sánchez Prada 2017-08-10 19:17:06 UTC
(In reply to Florian Müllner from comment #2)
> @@ +61,3 @@
>              this.actor.style = null;
>              this.actor.child = new St.Icon({ icon_name:
> 'avatar-default-symbolic',
> +                                             icon_size: this._iconSize *
> scaleFactor });
> 
> This looks wrong: the icon-size property inside StIcon is considered
> unscaled, and the scale is applied when the icon texture is loaded. So I'm
> pretty sure you are double-scaling here.

Yes, I've noticed that after submitting and already proposed a newer patch with that fixed, even before seeing your comment :-)

> ::: js/ui/userWidget.js
> @@ +57,3 @@
>              this.actor.child = null;
>              this.actor.style = 'background-image:
> url("%s");'.format(iconFile);
> +            this.actor.set_size(this._iconSize * scaleFactor,
> this._iconSize * scaleFactor);
> 
> I think you should move this out of the if-block: The actor has an explicit
> size (in _init), so we shouldn't rely on it to adjust its size to a resized
> child in the else-block.

I'm not sure I follow: if I moved this out of the if-block, wouldn't it be apply the scaling factor twice for the "else" side of the branch? Can you clarify? Thanks!
Comment 5 Florian Müllner 2017-08-10 19:34:04 UTC
(In reply to Mario Sánchez Prada from comment #4)
> I'm not sure I follow: if I moved this out of the if-block, wouldn't it be
> apply the scaling factor twice for the "else" side of the branch? Can you
> clarify? Thanks!

Currently the actor has a fixed size that is applied once during initialization. Your patch changes that to update the size in the if-block, but not in the else part - what I would expect from that is that the actor keeps its original fixed size, and the icon is scaled to fit the parent independent from the content size (that is determined by the icon-size parameter).

I did a quick test now (in lookingGlass):
  b = new St.Bin({ width: 32, height: 32 });
  Main.layoutManager.addChrome(b);
  b.child = new St.Icon({ icon_name: 'start-here', icon_size: 64 })
  b.child.width
     >>>> 32, not 64

I don't think it's different with the scale factor ...
Comment 6 Mario Sánchez Prada 2017-08-11 08:45:57 UTC
Created attachment 357396 [details] [review]
Resize the user's avatar when scaling factor changes

(In reply to Florian Müllner from comment #5)
> [...]
> Currently the actor has a fixed size that is applied once during
> initialization. Your patch changes that to update the size in the if-block,
> but not in the else part - what I would expect from that is that the actor
> keeps its original fixed size, and the icon is scaled to fit the parent
> independent from the content size (that is determined by the icon-size
> parameter).

Ah! Looks like I was mixing the actor with its child, and that's where the confusion came from, sorry about that. I understand what you mean now, thanks for the clarification.

See the new patch attached.
Comment 7 Florian Müllner 2017-08-11 09:45:47 UTC
Review of attachment 357396 [details] [review]:

LGTM