* bug#37752: Scaling factor inconsistencies between X with and without GTK
@ 2019-10-15 0:21 Carlos Pita
2019-10-15 7:56 ` Robert Pluim
0 siblings, 1 reply; 5+ messages in thread
From: Carlos Pita @ 2019-10-15 0:21 UTC (permalink / raw)
To: 37752
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
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#37752: Scaling factor inconsistencies between X with and without GTK
2019-10-15 0:21 bug#37752: Scaling factor inconsistencies between X with and without GTK Carlos Pita
@ 2019-10-15 7:56 ` Robert Pluim
2019-10-15 8:09 ` Carlos Pita
0 siblings, 1 reply; 5+ messages in thread
From: Robert Pluim @ 2019-10-15 7:56 UTC (permalink / raw)
To: Carlos Pita; +Cc: 37752
>>>>> On Mon, 14 Oct 2019 21:21:54 -0300, Carlos Pita <carlosjosepita@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
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#37752: Scaling factor inconsistencies between X with and without GTK
2019-10-15 7:56 ` Robert Pluim
@ 2019-10-15 8:09 ` Carlos Pita
2019-10-15 9:37 ` Robert Pluim
0 siblings, 1 reply; 5+ messages in thread
From: Carlos Pita @ 2019-10-15 8:09 UTC (permalink / raw)
To: Robert Pluim; +Cc: 37752
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37752: Scaling factor inconsistencies between X with and without GTK
2019-10-15 8:09 ` Carlos Pita
@ 2019-10-15 9:37 ` Robert Pluim
2019-10-15 22:40 ` Carlos Pita
0 siblings, 1 reply; 5+ messages in thread
From: Robert Pluim @ 2019-10-15 9:37 UTC (permalink / raw)
To: Carlos Pita; +Cc: 37752
>>>>> On Tue, 15 Oct 2019 05:09:04 -0300, Carlos Pita <carlosjosepita@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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-10-15 22:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-15 0:21 bug#37752: Scaling factor inconsistencies between X with and without GTK Carlos Pita
2019-10-15 7:56 ` Robert Pluim
2019-10-15 8:09 ` Carlos Pita
2019-10-15 9:37 ` Robert Pluim
2019-10-15 22:40 ` Carlos Pita
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).