bug#28605: 26.0.60; Part of leftmost character hidden

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson

Whenever I'm using two side-by-side windows, part of the leftmost
character in the right-side window is hidden.

This is when I use the Gnome HiDPI window scaling set to 2 to make text
readable on my 4K screen.

The problem is visible with emacs -Q --no-x-resources.
Turing on display-line-numbers-mode hides the problem, at least with the
default settings.

To reproduce:
emacs -Q --no-x-resources
M-x split-window-right
toggle the hidpi window scaling between 1 and 2.

I'm trying to attach a screenshot.

/Ola



In GNU Emacs 26.0.60 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-09-22 built on lnxolani1
Repository revision: d24ec5854098841388dfecf2c668e7f48f348af0
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 8.9 (jessie)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Making completion list...

Configured using:
 'configure --prefix=/opt/emacs/26'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LCMS2

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 94980 7152)
 (symbols 48 20380 1)
 (miscs 40 42 118)
 (strings 32 28398 1362)
 (string-bytes 1 735822)
 (vectors 16 14036)
 (vector-slots 8 490291 11606)
 (floats 8 53 90)
 (intervals 56 216 0)
 (buffers 992 12)
 (heap 1024 29846 1215))

Screenshot from 2017-09-26 11-50-13.png (937K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
 > Whenever I'm using two side-by-side windows, part of the leftmost
 > character in the right-side window is hidden.
 >
 > This is when I use the Gnome HiDPI window scaling set to 2 to make text
 > readable on my 4K screen.
 >
 > The problem is visible with emacs -Q --no-x-resources.
 > Turing on display-line-numbers-mode hides the problem, at least with the
 > default settings.
 >
 > To reproduce:
 > emacs -Q --no-x-resources
 > M-x split-window-right
 > toggle the hidpi window scaling between 1 and 2.
 >
 > I'm trying to attach a screenshot.

This could be bug#27830 reported by Kaushal Modi.  IIUC the left fringe
is completely missing in the window on the right.  Correct?

Please play around a bit with some settings: Turning on/off scroll bars,
moving them to the left, and reducing/enlarging the size of the left
fringe.  Also yet another C-x 3 to see whether only the last window on
the right is affected.  Maybe this could get us some insight.

And please also try with two variable settings: ‘frame-resize-pixelwise’
and ‘window-resize-pixelwise’ changed to non-nil, independently and
simultaneously.

Thanks in advance, martin

PS: Do you observe any strange positioning when popping up menus?  Some
people using window scaling of 2 have reported such behavior.




Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
On Wed, Sep 27, 2017 at 10:12 AM, martin rudalics <[hidden email]> wrote:

>> Whenever I'm using two side-by-side windows, part of the leftmost
>> character in the right-side window is hidden.
>>
>> This is when I use the Gnome HiDPI window scaling set to 2 to make text
>> readable on my 4K screen.
>>
>> The problem is visible with emacs -Q --no-x-resources.
>> Turing on display-line-numbers-mode hides the problem, at least with the
>> default settings.
>>
>> To reproduce:
>> emacs -Q --no-x-resources
>> M-x split-window-right
>> toggle the hidpi window scaling between 1 and 2.
>>
>> I'm trying to attach a screenshot.
>
> This could be bug#27830 reported by Kaushal Modi.  IIUC the left fringe
> is completely missing in the window on the right.  Correct?

It does seem the fringe is missing, but there is some other vertical bar
of empty space present.

> Please play around a bit with some settings: Turning on/off scroll bars,
> moving them to the left, and reducing/enlarging the size of the left
> fringe.  Also yet another C-x 3 to see whether only the last window on
> the right is affected.  Maybe this could get us some insight.

Turning off the scroll bar (scrollbar-mode nil) makes the fringe appear,
and the characters are fully visible.

Switching scroll bars off and from left to right with several
side-by-side windows
 shows that it is all window edges that are next to a scroll bar that
are affected.
The fringe is hidden, and the character at the edge is partially hidden.
The hidden character is a lot less obvious on the right side of a window.

> And please also try with two variable settings: ‘frame-resize-pixelwise’
> and ‘window-resize-pixelwise’ changed to non-nil, independently and
> simultaneously.

I'm not sure I did this right; I set the variables with customize and then
moved window and frame edges around a bit.
Made no difference as far as I can tell.

> Thanks in advance, martin
>
> PS: Do you observe any strange positioning when popping up menus?  Some
> people using window scaling of 2 have reported such behavior.

I hadn't noticed anything, so I tested

* mouse-1 on the size-indicator on the mode line, no problem
* clicking on the menus of the menu bar, no problem.

if there is something else you want me to try, please let me know.

I have noticed that the first menu i click in the menu bar does not
open, but if I then
use F10 to open the menu and step to it it will open fine after that.
Maybe it is
positioned somewhere I cannot see it?

--
Ola Nilsson



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
 > It does seem the fringe is missing, but there is some other vertical bar
 > of empty space present.

In fact, it appears so from the screenshot you sent.

 > Turning off the scroll bar (scrollbar-mode nil) makes the fringe appear,
 > and the characters are fully visible.

 From earlier reports, this seems to connect the problem to scaling.  To
make sure: You do not observe anything the like with scaling turned off?

 > Switching scroll bars off and from left to right with several
 > side-by-side windows
 >   shows that it is all window edges that are next to a scroll bar that
 > are affected.

You mean that the scroll bar from the window on the left affects the
things displayed in the window on the right?  We clear the background of
the scroll bars here and there.  Can you build Emacs yourself?  I could
try to make up a (non-sensical) patch which would turn these clearings
off to find out whether this is indeed the culprit.

 > I'm not sure I did this right; I set the variables with customize and then
 > moved window and frame edges around a bit.
 > Made no difference as far as I can tell.

OK.  I'm afraid that we sometimes don't draw things correctly on screen
with scaling turned on.  Maybe it's just x_fill_rectangle and/or
x_clear_area which are incompatible with GTK's ideas of scaling.

Two additional things you could try in this context: Can your turn on
window dividers and, independently, horizontal scroll bars (both from
the Options Show/Hide menu) and look whether they cause additional
problems?

martin



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
On Fri, Sep 29, 2017 at 10:36 AM, martin rudalics <[hidden email]> wrote:

>> It does seem the fringe is missing, but there is some other vertical bar
>> of empty space present.
>
> In fact, it appears so from the screenshot you sent.
>
>> Turning off the scroll bar (scrollbar-mode nil) makes the fringe appear,
>> and the characters are fully visible.
>
> From earlier reports, this seems to connect the problem to scaling.  To
> make sure: You do not observe anything the like with scaling turned off?

I've only seen this on my work system with Debian 8 and the hidpi monitor.
I tried on my home system with debian 9 and an old non-hidpi monitor and
did not see the problem.  Remoting to my work machine and exporting the
emacs window through X, and then using the scaling on my home system
did not show the problem.

>> Switching scroll bars off and from left to right with several
>> side-by-side windows
>>   shows that it is all window edges that are next to a scroll bar that
>> are affected.
>
> You mean that the scroll bar from the window on the left affects the
> things displayed in the window on the right?

Yes, the scroll bar affects the window on both sides. It's only the frame edge
with no scroll bar that shows a fringe.

> We clear the background of
> the scroll bars here and there.  Can you build Emacs yourself?  I could
> try to make up a (non-sensical) patch which would turn these clearings
> off to find out whether this is indeed the culprit.

I do build emacs myself, this is all on the emacs-26 branch. I can
rebuild with a patch.

>> I'm not sure I did this right; I set the variables with customize and then
>> moved window and frame edges around a bit.
>> Made no difference as far as I can tell.
>
> OK.  I'm afraid that we sometimes don't draw things correctly on screen
> with scaling turned on.  Maybe it's just x_fill_rectangle and/or
> x_clear_area which are incompatible with GTK's ideas of scaling.

The hidpi scaling in gnome works only so far, and I'm not sure all of gtk
is aware of the setting. But then I know next to nothing about gtk.
The menu-bar and scroll-bars get decent size, but I select a larger font
for emacs using X resources (turned off for the report). I noticed
yesterday that the fringes are dis-proportionally narrow and the fringe
symbols almost unreadable.

> Two additional things you could try in this context: Can your turn on
> window dividers and, independently, horizontal scroll bars (both from
> the Options Show/Hide menu) and look whether they cause additional
> problems?

I've had horizontal scroll bars disabled the entire time. I'll try the dividers
when I'm back at my machine again.

--
Ola Nilsson



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
 >> You mean that the scroll bar from the window on the left affects the
 >> things displayed in the window on the right?
 >
 > Yes, the scroll bar affects the window on both sides. It's only the frame edge
 > with no scroll bar that shows a fringe.

Can you please be a bit more precise: How would the scroll bar affect
the window on _both_ sides?  Does the scroll bar also affect the
contents of the window it belongs to?

 > The hidpi scaling in gnome works only so far, and I'm not sure all of gtk
 > is aware of the setting. But then I know next to nothing about gtk.
 > The menu-bar and scroll-bars get decent size, but I select a larger font
 > for emacs using X resources (turned off for the report). I noticed
 > yesterday that the fringes are dis-proportionally narrow and the fringe
 > symbols almost unreadable.

On a frame with such bad fringes please do

M-: (window--dump-frame) RET

This should get you a buffer with the name *window-frame-dump*.  Please
post the contents of that buffer here.

Thanks, martin



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
On Fri, Sep 29, 2017 at 8:18 PM, martin rudalics <[hidden email]> wrote:

>>> You mean that the scroll bar from the window on the left affects the
>>> things displayed in the window on the right?
>>
>> Yes, the scroll bar affects the window on both sides. It's only the frame
>> edge
>> with no scroll bar that shows a fringe.
>
> Can you please be a bit more precise: How would the scroll bar affect
> the window on _both_ sides?  Does the scroll bar also affect the
> contents of the window it belongs to?
If the frame contains three side-by-side windows and scroll bars on
the right I expect to see (from left to right):

frame border
left fringe for window one
window one
right fringe for window one
scroll bar for window one
right fringe for window two
window two
left fringe for window two
scroll bar for window two
right fringe for window three
window three
left fringe  for window three
scroll bar for window three
frame border

Of all the fringes, only the left fringe of window one is visible.
Using scroll bars on the left, only the right fringe of window three
is visible.
In both cases, characters that are next to non-visible/hidden fringes
are partially hidden.
I'm attaching two screenshots that should show this.

I bit the bullet and did a git bisect:

36cf0791ba75ee16dfbedfe437567ec6dd945b8a is the first bad commit
commit 36cf0791ba75ee16dfbedfe437567ec6dd945b8a
Author: Lars Ingebrigtsen <[hidden email]>
Date:   Sun Jul 16 16:50:57 2017 +0200
    Remove usage of the GDK_SCALE variable

    * src/gtkutil.c (xg_get_gdk_scale): Remove.
    (xg_get_default_scrollbar_height)
    (xg_get_default_scrollbar_width): Pass in a frame to check for
    scaling.
    (xg_frame_set_char_size): Use the API for querying scale
    instead of looking at the GDK_SCALE variable.
    (xg_get_default_scrollbar_width): Ditto.
    (xg_get_default_scrollbar_height): Ditto.
    (xg_update_scrollbar_pos): Ditto.

    * src/xfns.c (x_set_scroll_bar_default_height): Pass in the
    frame to get the width.


I also played with the dividers and horizontal scroll bars.

The horizontal scroll bars are not visibla at all with scaling on.
Dividers on the right fixed the hidden character problem but not the
hidden fringes,

I attach some screenshots of this as well.


>> The hidpi scaling in gnome works only so far, and I'm not sure all of gtk
>> is aware of the setting. But then I know next to nothing about gtk.
>> The menu-bar and scroll-bars get decent size, but I select a larger font
>> for emacs using X resources (turned off for the report). I noticed
>> yesterday that the fringes are dis-proportionally narrow and the fringe
>> symbols almost unreadable.
>
> On a frame with such bad fringes please do
>
> M-: (window--dump-frame) RET
This is with emacs -Q --no-x-resources, dividers off, horizontal scrollbars off.

frame pixel: 2034 x 466   cols/lines: 226 x 25   units: 9 x 18
frame text pixel: 1992 x 466   cols/lines: 221 x 25
tool: 0  scroll: 26/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 5>   parent: nil
pixel left: 0   top: 0   size: 2034 x 448   new: 448
char left: 0   top: 0   size: 226 x 25   new: 25
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 5>
pixel left: 0   top: 0   size: 1020 x 448   new: 448
char left: 0   top: 0   size: 113 x 25   new: 25
normal: 0.5 x 1.0   new: nil
body pixel: 978 x 430   char: 108 x 23
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 26  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 6 on *scratch*>   parent: #<window 5>
pixel left: 1020   top: 0   size: 1014 x 448   new: 448
char left: 113   top: 0   size: 113 x 25   new: 25
normal: 0.5 x 1.0   new: nil
body pixel: 972 x 430   char: 108 x 23
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 26  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 448   size: 2034 x 18   new: 0
char left: 0   top: 25   size: 226 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 1992 x 18   char: 221 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 26  divider: 0
height header-line: 0  mode-line: 0  divider: 0

--
Ola Nilsson

with-hidpi-scaling.png (82K) Download Attachment
without-hidpi-scaling.png (58K) Download Attachment
horizontal-scrollbars-no-dividers.png (244K) Download Attachment
horizontal-scrollbars-right-dividers.png (249K) Download Attachment
no-horizontal-scrollbars-right-dividers.png (247K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
 > If the frame contains three side-by-side windows and scroll bars on
 > the right I expect to see (from left to right):
 >
 > frame border
 > left fringe for window one
 > window one
 > right fringe for window one
 > scroll bar for window one
 > right fringe for window two
 > window two
 > left fringe for window two
 > scroll bar for window two
 > right fringe for window three
 > window three
 > left fringe  for window three
 > scroll bar for window three
 > frame border
 >
 > Of all the fringes, only the left fringe of window one is visible.
 > Using scroll bars on the left, only the right fringe of window three
 > is visible.
 > In both cases, characters that are next to non-visible/hidden fringes
 > are partially hidden.
 > I'm attaching two screenshots that should show this.

Thanks for the details.  From your initial screenshot it was not clear
to me that the effect is really that bad.

 > I bit the bullet and did a git bisect:
 >
 > 36cf0791ba75ee16dfbedfe437567ec6dd945b8a is the first bad commit
 > commit 36cf0791ba75ee16dfbedfe437567ec6dd945b8a
 > Author: Lars Ingebrigtsen <[hidden email]>
 > Date:   Sun Jul 16 16:50:57 2017 +0200
 >      Remove usage of the GDK_SCALE variable
 >
 >      * src/gtkutil.c (xg_get_gdk_scale): Remove.
 >      (xg_get_default_scrollbar_height)
 >      (xg_get_default_scrollbar_width): Pass in a frame to check for
 >      scaling.
 >      (xg_frame_set_char_size): Use the API for querying scale
 >      instead of looking at the GDK_SCALE variable.
 >      (xg_get_default_scrollbar_width): Ditto.
 >      (xg_get_default_scrollbar_height): Ditto.
 >      (xg_update_scrollbar_pos): Ditto.
 >
 >      * src/xfns.c (x_set_scroll_bar_default_height): Pass in the
 >      frame to get the width.

Great.  Lars, how should we proceed from here?

(1) Revert that commit.

(2) Revert the call of gtk_widget_get_scale_factor only.

(3) Try to fix the build with your change in place.

(4) Provide some option so that users can either use your approach or
     Jan's.  The default should prefer Jan's setup to avoid that users
     like Ola have to go through this again.

 > I also played with the dividers and horizontal scroll bars.
 >
 > The horizontal scroll bars are not visibla at all with scaling on.

Apparently, the horizontal scroll bar code does not handle scaling.  If
we fix the current problem, maybe you could help me fix that one too.

 > Dividers on the right fixed the hidden character problem but not the
 > hidden fringes,

Yes.  IMHO it's because the scroll bar clearing code hides the dividers
instead of the text.  If you customize dividers to a sufficiently large
width you should be able to make the entire text visible and even parts
of the dividers (on the left side of a window, only - the right sides
will remain obscured as before).

 > I attach some screenshots of this as well.

Very informative, thanks.  One thing that stupefies me about these
screenshots is that the menu and toolbar items are smaller in
horizontal-scrollbars-no-dividers.png than in with-hidpi-scaling.png.

 > This is with emacs -Q --no-x-resources, dividers off, horizontal scrollbars off.
 >
 > frame pixel: 2034 x 466   cols/lines: 226 x 25   units: 9 x 18
[...]
 > height header-line: 0  mode-line: 0  divider: 0

All these values are completely as expected so the problem must be
confined to this x_clear_area call in xg_update_scrollbar_pos in
gtkutil.c

           /* Clear under old scroll bar position.  */
           oldw += (scale - 1) * oldw;
          oldx -= (scale - 1) * oldw;
           x_clear_area (f, oldx, oldy, oldw, oldh);

where the value of scale is now obtained via

       int scale = xg_get_scale (f);

If you replace the latter by the old

       int scale = xg_get_gdk_scale ();

does your problem go away?  If so, then it would be interesting how the
values returned by xg_get_scale differ with gtk_widget_get_scale_factor
and xg_get_gdk_scale called.

Thanks, martin

CC-ing Kaushal Modi: Is this the same problem as the one you posted in
Bug#27830?



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Lars Ingebrigtsen
martin rudalics <[hidden email]> writes:

> Great.  Lars, how should we proceed from here?
>
> (1) Revert that commit.

Rather not, because it makes using Emacs on Ubuntu 17.04 with a hiDPI
display very awkward.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
In reply to this post by martin rudalics
On Tue, Oct 3, 2017 at 11:15 AM, martin rudalics <[hidden email]> wrote:

>> If the frame contains three side-by-side windows and scroll bars on
>> the right I expect to see (from left to right):
>>
>> frame border
>> left fringe for window one
>> window one
>> right fringe for window one
>> scroll bar for window one
>> right fringe for window two
>> window two
>> left fringe for window two
>> scroll bar for window two
>> right fringe for window three
>> window three
>> left fringe  for window three
>> scroll bar for window three
>> frame border
>>
>> Of all the fringes, only the left fringe of window one is visible.
>> Using scroll bars on the left, only the right fringe of window three
>> is visible.
>> In both cases, characters that are next to non-visible/hidden fringes
>> are partially hidden.
>> I'm attaching two screenshots that should show this.
>
> Thanks for the details.  From your initial screenshot it was not clear
> to me that the effect is really that bad.
>
>> I bit the bullet and did a git bisect:
>>
>> 36cf0791ba75ee16dfbedfe437567ec6dd945b8a is the first bad commit
>> commit 36cf0791ba75ee16dfbedfe437567ec6dd945b8a
>> Author: Lars Ingebrigtsen <[hidden email]>
>> Date:   Sun Jul 16 16:50:57 2017 +0200
>>      Remove usage of the GDK_SCALE variable
>>
>>      * src/gtkutil.c (xg_get_gdk_scale): Remove.
>>      (xg_get_default_scrollbar_height)
>>      (xg_get_default_scrollbar_width): Pass in a frame to check for
>>      scaling.
>>      (xg_frame_set_char_size): Use the API for querying scale
>>      instead of looking at the GDK_SCALE variable.
>>      (xg_get_default_scrollbar_width): Ditto.
>>      (xg_get_default_scrollbar_height): Ditto.
>>      (xg_update_scrollbar_pos): Ditto.
>>
>>      * src/xfns.c (x_set_scroll_bar_default_height): Pass in the
>>      frame to get the width.
>
> Great.  Lars, how should we proceed from here?
>
> (1) Revert that commit.
>
> (2) Revert the call of gtk_widget_get_scale_factor only.
>
> (3) Try to fix the build with your change in place.
>
> (4) Provide some option so that users can either use your approach or
>     Jan's.  The default should prefer Jan's setup to avoid that users
>     like Ola have to go through this again.
>
>> I also played with the dividers and horizontal scroll bars.
>>
>> The horizontal scroll bars are not visibla at all with scaling on.
>
> Apparently, the horizontal scroll bar code does not handle scaling.  If
> we fix the current problem, maybe you could help me fix that one too.
>
>> Dividers on the right fixed the hidden character problem but not the
>> hidden fringes,
>
> Yes.  IMHO it's because the scroll bar clearing code hides the dividers
> instead of the text.  If you customize dividers to a sufficiently large
> width you should be able to make the entire text visible and even parts
> of the dividers (on the left side of a window, only - the right sides
> will remain obscured as before).
>
>> I attach some screenshots of this as well.
>
> Very informative, thanks.  One thing that stupefies me about these
> screenshots is that the menu and toolbar items are smaller in
> horizontal-scrollbars-no-dividers.png than in with-hidpi-scaling.png.
>
>> This is with emacs -Q --no-x-resources, dividers off, horizontal
>> scrollbars off.
>>
>> frame pixel: 2034 x 466   cols/lines: 226 x 25   units: 9 x 18
> [...]
>> height header-line: 0  mode-line: 0  divider: 0
>
> All these values are completely as expected so the problem must be
> confined to this x_clear_area call in xg_update_scrollbar_pos in
> gtkutil.c
>
>           /* Clear under old scroll bar position.  */
>           oldw += (scale - 1) * oldw;
>           oldx -= (scale - 1) * oldw;
>           x_clear_area (f, oldx, oldy, oldw, oldh);
>
> where the value of scale is now obtained via
>
>       int scale = xg_get_scale (f);
>
> If you replace the latter by the old
>
>       int scale = xg_get_gdk_scale ();
>
> does your problem go away?  If so, then it would be interesting how the
> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
> and xg_get_gdk_scale called.

Made no difference what I can see, except a lot of messages :

(emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
assertion 'extra_space >= 0' failed

I tested with dividers and horizontal scrollbars with the same results
as before.

--
Ola Nilsson



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Robert Pluim
Ola Nilsson <[hidden email]> writes:

>> does your problem go away?  If so, then it would be interesting how the
>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>> and xg_get_gdk_scale called.
>
> Made no difference what I can see, except a lot of messages :
>
> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> assertion 'extra_space >= 0' failed

Through inspection I noticed we're not adjusting the width of the
scrollbar for the scale. Does the following help?

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 0da7039..60ba627 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
       top /= scale;
       left /= scale;
       height /= scale;
+      width /= scale;
       left -= (scale - 1) * ((width / scale) >> 1);
 
       /* Clear out old position.  */



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Kaushal Modi
In reply to this post by martin rudalics
On Tue, Oct 3, 2017 at 5:16 AM martin rudalics <[hidden email]> wrote:
Thanks for the details.  From your initial screenshot it was not clear
to me that the effect is really that bad.

I don't see that bad of an effect. I only see, may be a pixel of the left side of the fringe getting truncated.
 
CC-ing Kaushal Modi: Is this the same problem as the one you posted in
Bug#27830?

Thanks for looping me in. Here's a little gif that shows the problem. Looks like the problem shows up only when disabling both scroll bars AND window dividers (I have them off by default).


It might be difficult to see even in this gif.. but we are looking for a green bracket covering all the newly added lines after the last git commit (diff-hl package). Notice that the vertical part of the green bracket in the fringe hides when both scroll-bar and window dividers are hidden.

@martin Apologies for not being able to follow up in my debbugs thread https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830 I'll find some time today to provide you with more debug info in that thread. In the meanwhile, see if this gif provides you any hints.






-----
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
In reply to this post by Robert Pluim
On Tue, Oct 3, 2017 at 3:08 PM, Robert Pluim <[hidden email]> wrote:

> Ola Nilsson <[hidden email]> writes:
>
>>> does your problem go away?  If so, then it would be interesting how the
>>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>>> and xg_get_gdk_scale called.
>>
>> Made no difference what I can see, except a lot of messages :
>>
>> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
>> assertion 'extra_space >= 0' failed
>
> Through inspection I noticed we're not adjusting the width of the
> scrollbar for the scale. Does the following help?
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 0da7039..60ba627 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
>        top /= scale;
>        left /= scale;
>        height /= scale;
> +      width /= scale;
>        left -= (scale - 1) * ((width / scale) >> 1);
>
>        /* Clear out old position.  */
This works for me:

@@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
       top /= scale;
       left /= scale;
       height /= scale;
-      left -= (scale - 1) * ((width / scale) >> 1);
+      width /= scale;

       /* Clear out old position.  */
       int oldx = -1, oldy = -1, oldw, oldh;

Screenshots included.

The horizontal scroll bars are still no-show.

As a funny side effect, each time I turn vertical scrollbars on or off
(not switching sides) the frame shrinks with about two lines.

--
Ola Nilsson

ok.png (78K) Download Attachment
ok-dividers.png (84K) Download Attachment
horizontal-still-not-ok.png (83K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson


On Oct 3, 2017 17:49, "Ola Nilsson" <[hidden email]> wrote:
On Tue, Oct 3, 2017 at 3:08 PM, Robert Pluim <[hidden email]> wrote:
> Ola Nilsson <[hidden email]> writes:
>
>>> does your problem go away?  If so, then it would be interesting how the
>>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>>> and xg_get_gdk_scale called.
>>
>> Made no difference what I can see, except a lot of messages :
>>
>> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
>> assertion 'extra_space >= 0' failed
>
> Through inspection I noticed we're not adjusting the width of the
> scrollbar for the scale. Does the following help?
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 0da7039..60ba627 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
>        top /= scale;
>        left /= scale;
>        height /= scale;
> +      width /= scale;
>        left -= (scale - 1) * ((width / scale) >> 1);
>
>        /* Clear out old position.  */

This works for me:

@@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
       top /= scale;
       left /= scale;
       height /= scale;
-      left -= (scale - 1) * ((width / scale) >> 1);
+      width /= scale;

       /* Clear out old position.  */
       int oldx = -1, oldy = -1, oldw, oldh;

I just realized that I never tested with scaling off. 

/Ola Nilsson 

Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
On Tue, Oct 3, 2017 at 6:58 PM, Ola Nilsson <[hidden email]> wrote:

>
>
> On Oct 3, 2017 17:49, "Ola Nilsson" <[hidden email]> wrote:
>
> On Tue, Oct 3, 2017 at 3:08 PM, Robert Pluim <[hidden email]> wrote:
>> Ola Nilsson <[hidden email]> writes:
>>
>>>> does your problem go away?  If so, then it would be interesting how the
>>>> values returned by xg_get_scale differ with gtk_widget_get_scale_factor
>>>> and xg_get_gdk_scale called.
>>>
>>> Made no difference what I can see, except a lot of messages :
>>>
>>> (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
>>> assertion 'extra_space >= 0' failed
>>
>> Through inspection I noticed we're not adjusting the width of the
>> scrollbar for the scale. Does the following help?
>>
>> diff --git a/src/gtkutil.c b/src/gtkutil.c
>> index 0da7039..60ba627 100644
>> --- a/src/gtkutil.c
>> +++ b/src/gtkutil.c
>> @@ -3879,6 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
>>        top /= scale;
>>        left /= scale;
>>        height /= scale;
>> +      width /= scale;
>>        left -= (scale - 1) * ((width / scale) >> 1);
>>
>>        /* Clear out old position.  */
>
> This works for me:
>
> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
>        top /= scale;
>        left /= scale;
>        height /= scale;
> -      left -= (scale - 1) * ((width / scale) >> 1);
> +      width /= scale;
>
>        /* Clear out old position.  */
>        int oldx = -1, oldy = -1, oldw, oldh;
>
>
> I just realized that I never tested with scaling off.
I did some more tests this morning.

With scaling set to 1 (off) the scroll bars look like the attached screenshot.
But they look like that without the patch I sent too.
I have not noticed this on my other system where I have a normal monitor.

--
Ola Nilsson

Screenshot from 2017-10-04 08-42-14.png (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
In reply to this post by Ola Nilsson
 > Made no difference what I can see, except a lot of messages :
 >
 > (emacs:2302): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
 > assertion 'extra_space >= 0' failed

Hmmm...  I could have sworn that using xg_get_gdk_scale would have tried
to clear entirely within the region cleared by xg_get_scale.  Apparently
I failed or some boundaries became negative instead.

Sorry for the miss, martin



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
In reply to this post by Ola Nilsson
 > This works for me:
 >
 > @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
 >         top /= scale;
 >         left /= scale;
 >         height /= scale;
 > -      left -= (scale - 1) * ((width / scale) >> 1);
 > +      width /= scale;

Deceptively simple.  Whatever was that left rigmarole needed for?
What changes with

       width /= scale;
       left -= (scale - 1) * (width >> 1);

 > The horizontal scroll bars are still no-show.

With scaling on their positions are apparently off-window.  Some
clearing effect is visible in horizontal-still-not-ok.png but might be
off as well.

 > As a funny side effect, each time I turn vertical scrollbars on or off
 > (not switching sides) the frame shrinks with about two lines.

This would be too strange.  I suppose it comes from turning on and off
_horizontal_ scroll bars.  Just as turning vertical scroll bars on and
off should shrink your frame by about two columns.

martin



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

martin rudalics
In reply to this post by Ola Nilsson
 >> I just realized that I never tested with scaling off.
 >
 > I did some more tests this morning.
 >
 > With scaling set to 1 (off) the scroll bars look like the attached screenshot.
 > But they look like that without the patch I sent too.
 > I have not noticed this on my other system where I have a normal monitor.

IIUC this is a GTK idiosyncrasy where the scroll bar width is determined
by the theme and Emacs cannot deal with it correctly.

See update_theme_scrollbar_width in gtkutil.c

martin



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Ola Nilsson
In reply to this post by martin rudalics
On Wed, Oct 4, 2017 at 11:05 AM, martin rudalics <[hidden email]> wrote:

>On Tue, Oct 3, 2017 at 6:58 PM, Ola Nilsson <[hidden email]> wrote:
>> This works for me:
>>
>> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
>>         top /= scale;
>>         left /= scale;
>>         height /= scale;
>> -      left -= (scale - 1) * ((width / scale) >> 1);
>> +      width /= scale;
>
> Deceptively simple.  Whatever was that left rigmarole needed for?
> What changes with
>
>       width /= scale;
>       left -= (scale - 1) * (width >> 1);

From the top of my head, the vertical scrollbar is placed to far to the left
overlapping the window to the left and leaving a white band between the
scroll bar and the left-fringe of the window to the right.
It does nothing if scale is 1, obviously.

--
Ola Nilsson



Reply | Threaded
Open this post in threaded view
|

bug#28605: 26.0.60; Part of leftmost character hidden

Robert Pluim
Ola Nilsson <[hidden email]> writes:

> On Wed, Oct 4, 2017 at 11:05 AM, martin rudalics <[hidden email]> wrote:
>>On Tue, Oct 3, 2017 at 6:58 PM, Ola Nilsson <[hidden email]> wrote:
>>> This works for me:
>>>
>>> @@ -3883,7 +3883,7 @@ xg_update_scrollbar_pos (struct frame *f,
>>>         top /= scale;
>>>         left /= scale;
>>>         height /= scale;
>>> -      left -= (scale - 1) * ((width / scale) >> 1);
>>> +      width /= scale;
>>
>> Deceptively simple.  Whatever was that left rigmarole needed for?
>> What changes with
>>
>>       width /= scale;
>>       left -= (scale - 1) * (width >> 1);
>
> From the top of my head, the vertical scrollbar is placed to far to the left
> overlapping the window to the left and leaving a white band between the
> scroll bar and the left-fringe of the window to the right.
> It does nothing if scale is 1, obviously.

Yes, I think removing the calculation for left is the correct fix (at
least it looks correct here). The horizontal scrollbars need fixing as
well, see below. xg_update_scrollbar_pos and xg_update_horizontal_scrollbar_pos
are now 99% identical apart from the 'hidden' check.

I don't think this will be the final version: I sometimes get the echo
area being the wrong size...

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 0da7039..b41e8f1 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3879,7 +3879,7 @@ xg_update_scrollbar_pos (struct frame *f,
       top /= scale;
       left /= scale;
       height /= scale;
-      left -= (scale - 1) * ((width / scale) >> 1);
+      width /= scale;
 
       /* Clear out old position.  */
       int oldx = -1, oldy = -1, oldw, oldh;
@@ -3955,6 +3955,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
       GtkWidget *wfixed = f->output_data.x->edit_widget;
       GtkWidget *wparent = gtk_widget_get_parent (wscroll);
       gint msl;
+      int scale = xg_get_scale (f);
+
+      top /= scale;
+      left /= scale;
+      height /= scale;
+      width /= scale;
 
       /* Clear out old position.  */
       int oldx = -1, oldy = -1, oldw, oldh;
@@ -3981,8 +3987,12 @@ xg_update_horizontal_scrollbar_pos (struct frame *f,
           gtk_widget_set_size_request (wscroll, width, height);
         }
       if (oldx != -1 && oldw > 0 && oldh > 0)
-        /* Clear under old scroll bar position.  */
-        x_clear_area (f, oldx, oldy, oldw, oldh);
+       {
+         /* Clear under old scroll bar position.  */
+         oldw += (scale - 1) * oldw;
+         oldx -= (scale - 1) * oldw;
+         x_clear_area (f, oldx, oldy, oldw, oldh);
+       }
 
       /* GTK does not redraw until the main loop is entered again, but
          if there are no X events pending we will not enter it.  So we sync




12345