GNU bug report logs - #37752
Scaling factor inconsistencies between X with and without GTK

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37752 in the body.
You can then email your comments to 37752 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Scaling factor inconsistencies between X with and without GTK
Date: Mon, 14 Oct 2019 21:21:54 -0300

In many places in xterm.c you have code like:

#ifdef USE_GTK
  scale = xg_get_scale (f);
#endif

Sometimes scale is only used in GTK specific code and that's ok.

But sometimes it's used in code that's not particular to GTK, for example:

int scale = 1;
#ifdef USE_GTK
  scale = xg_get_scale (f);
#endif
FRAME_CR_SURFACE (f) =
    cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
      scale * FRAME_PIXEL_WIDTH (f),
      scale * FRAME_PIXEL_HEIGHT (f));

Besides, there is x_get_scale_factor, also defined in xterm.c, which
computes the scaling factor in a GTK-independent way, and also
discriminates between x and y scaling factors. It's only used by
x_draw_underwave.

I would like to abstract both cases inside x_get_scale_factor, that
would then use xg_get_scale if in GTK or compute just one scaling
factor (for x or for y) otherwise. Notice that given that the scaling
factor is the ratio of the effective resolution to a base resolution
of 96 dpi *truncated down* to the nearest integer, AFAICS it's almost
impossible to get different scaling factors for x and for y.

What do you think?

Best regards
--
Carlos

Message #8 received at 37752 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 37752 <at> debbugs.gnu.org
Subject: Re: bug#37752: Scaling factor inconsistencies between X with and
 without GTK
Date: Tue, 15 Oct 2019 09:56:46 +0200

>>>>> On Mon, 14 Oct 2019 21:21:54 -0300, Carlos Pita <carlosjosepita <at> gmail.com> said:

    Carlos> In many places in xterm.c you have code like:
    Carlos> #ifdef USE_GTK
    Carlos>   scale = xg_get_scale (f);
    Carlos> #endif

    Carlos> Sometimes scale is only used in GTK specific code and that's ok.

    Carlos> But sometimes it's used in code that's not particular to GTK, for example:

    Carlos> int scale = 1;
    Carlos> #ifdef USE_GTK
    Carlos>   scale = xg_get_scale (f);
    Carlos> #endif
    Carlos> FRAME_CR_SURFACE (f) =
    Carlos>     cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
    Carlos>       scale * FRAME_PIXEL_WIDTH (f),
    Carlos>       scale * FRAME_PIXEL_HEIGHT (f));

I canʼt find that code in master.

    Carlos> Besides, there is x_get_scale_factor, also defined in xterm.c, which
    Carlos> computes the scaling factor in a GTK-independent way, and also
    Carlos> discriminates between x and y scaling factors. It's only used by
    Carlos> x_draw_underwave.

    Carlos> I would like to abstract both cases inside x_get_scale_factor, that
    Carlos> would then use xg_get_scale if in GTK or compute just one scaling
    Carlos> factor (for x or for y) otherwise. Notice that given that the scaling
    Carlos> factor is the ratio of the effective resolution to a base resolution
    Carlos> of 96 dpi *truncated down* to the nearest integer, AFAICS it's almost
    Carlos> impossible to get different scaling factors for x and for y.

Sure, that makes sense. Do you have a test case showing a display
difference, or is this just code cleanup?

Robert

Message #11 received at 37752 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 37752 <at> debbugs.gnu.org
Subject: Re: bug#37752: Scaling factor inconsistencies between X with and
 without GTK
Date: Tue, 15 Oct 2019 05:09:04 -0300

>     Carlos> int scale = 1;
>     Carlos> #ifdef USE_GTK
>     Carlos>   scale = xg_get_scale (f);
>     Carlos> #endif
>     Carlos> FRAME_CR_SURFACE (f) =
>     Carlos>     cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
>     Carlos>       scale * FRAME_PIXEL_WIDTH (f),
>     Carlos>       scale * FRAME_PIXEL_HEIGHT (f));
>
> I canʼt find that code in master.

You're right, this and other xg_get_scale usages were removed wrt
emacs-26. Just one of them remains.

> Sure, that makes sense. Do you have a test case showing a display
> difference, or is this just code cleanup?

It's just code cleanup.

Best regards
--
Carlos

Message #14 received at 37752 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 37752 <at> debbugs.gnu.org
Subject: Re: bug#37752: Scaling factor inconsistencies between X with and
 without GTK
Date: Tue, 15 Oct 2019 11:37:02 +0200

>>>>> On Tue, 15 Oct 2019 05:09:04 -0300, Carlos Pita <carlosjosepita <at> gmail.com> said:

    Carlos> int scale = 1;
    Carlos> #ifdef USE_GTK
    Carlos> scale = xg_get_scale (f);
    Carlos> #endif
    Carlos> FRAME_CR_SURFACE (f) =
    Carlos> cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
    Carlos> scale * FRAME_PIXEL_WIDTH (f),
    Carlos> scale * FRAME_PIXEL_HEIGHT (f));
    >> 
    >> I canʼt find that code in master.

    Carlos> You're right, this and other xg_get_scale usages were removed wrt
    Carlos> emacs-26. Just one of them remains.

If thatʼs in code thatʼs independent of GTK3 usage, then by all means
fix it.

Robert

Message #19 received at 37752-close <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 37752-close <at> debbugs.gnu.org
Subject: Re: bug#37752: Scaling factor inconsistencies between X with and
 without GTK
Date: Tue, 15 Oct 2019 19:40:02 -0300

Hi Robert, I'm closing this in favor of

#37770 [PATCH] Expose scale factor through the redisplay interface

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37770

Please take a look at it if you're so kind.

Best regards
--
Carlos

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.