bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Yuuki Harano]

On Mon, 22 Nov 2021 12:43:57 -0500,
	Fred Fu <moonsolo@gmail.com> wrote:
> Here are the minimal steps to reproduce with emacs -Q:
> 
> 1. move the frame to the right display (using super+shift+right)
> 
> 2. make the emacs frame fullscreen (using super+up). See the attached
> image file named "start".
> 
> 3. move it to the middle display (using super+shift+left). The frame
> gets stretched over the two displays. See the attached image file
> named "stretched".
> 
> 4. move it to the middle display again (using super+shift+left). The
> frame now looks right on the middle display. See the attached image
> file named "end".

Thanks for the steps to reproduce.
But I don't have 3 monitors, so I can't reproduce it.

-- 
Yuuki Harano

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Fred Fu]

Hi Yuuki,

The stretching issue seems a Gnome/Mutter issue, because other GTK
applications have the same problem.
But that the text becomes blurry only happens to the pgtk port.

On Tue, Nov 30, 2021 at 10:59 AM Yuuki Harano <masm+emacs@masm11.me> wrote:
>
>
> On Mon, 22 Nov 2021 12:43:57 -0500,
>         Fred Fu <moonsolo@gmail.com> wrote:
> > Here are the minimal steps to reproduce with emacs -Q:
> >
> > 1. move the frame to the right display (using super+shift+right)
> >
> > 2. make the emacs frame fullscreen (using super+up). See the attached
> > image file named "start".
> >
> > 3. move it to the middle display (using super+shift+left). The frame
> > gets stretched over the two displays. See the attached image file
> > named "stretched".
> >
> > 4. move it to the middle display again (using super+shift+left). The
> > frame now looks right on the middle display. See the attached image
> > file named "end".
>
> Thanks for the steps to reproduce.
> But I don't have 3 monitors, so I can't reproduce it.

I don't think three monitors are needed. Two monitors, one scaled@2x
and one @1x, should be enough to reproduce the issue.

That said, I'd love to help debug this issue on my end, but I don't
know what to start with. Any ideas?


> --
> Yuuki Harano



-- 
Best regards
F

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Yuuki Harano]

On Tue, 30 Nov 2021 11:10:37 -0500,
	Fred Fu <moonsolo@gmail.com> wrote:
> I don't think three monitors are needed. Two monitors, one scaled@2x
> and one @1x, should be enough to reproduce the issue.

Reproduced.
I have a TV, that can be connected to my note PC, and tried GNOME(Wayland).
The PC's monitor is 2x and the TV is 1x.
I moved a pgtk emacs frame from the TV to the PC's monitor, and it became
blurry.  When I resized it, it recovered.

> That said, I'd love to help debug this issue on my end, but I don't
> know what to start with. Any ideas?

I have a cairo_surface_t and draw on it.  And I copy it on gtk window
when gtk wants so.
I don't scale fonts explicitly.  Scaling is done implicitly by compositor,
gtk, and cairo.

My guess:
cairo_surface_t is bitmap.
On 1x, cairo_surface_t has non-scaled texts, and it is drawn on
gtk window as is.
When I move it to 2x, cairo_surface_t is drawn on gtk window
at double size.  It is blurry, because cairo_surface_it is bitmap.
When I resize it, I recreate cairo_surface_t of logical size.
When that, cairo_surface_t is double size implicitly.
cairo_surface_t has 2x scaled texts.  It is not blurry, because
fonts are vector graphics.
It is drawn on gtk window as is.

Maybe, I need to recreate cairo_surface_t when monitor
is changed.  I looked for such a signal but nothing found.

-- 
Yuuki Harano

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Fred Fu]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

I have zero knowledge of GTK thus I have some dump questions:

How do GTK applications handle this situation?

Does each gnome app deal with their windows moving among displays of scale
factors on their own?

Or do they just delegate the dirty job to GTK or other lower-level
mechanisms?

On Wed, Dec 1, 2021, 10:09 AM Yuuki Harano <masm+emacs@masm11.me> wrote:

>
> On Tue, 30 Nov 2021 11:10:37 -0500,
>         Fred Fu <moonsolo@gmail.com> wrote:
> > I don't think three monitors are needed. Two monitors, one scaled@2x
> > and one @1x, should be enough to reproduce the issue.
>
> Reproduced.
> I have a TV, that can be connected to my note PC, and tried GNOME(Wayland).
> The PC's monitor is 2x and the TV is 1x.
> I moved a pgtk emacs frame from the TV to the PC's monitor, and it became
> blurry.  When I resized it, it recovered.
>
> > That said, I'd love to help debug this issue on my end, but I don't
> > know what to start with. Any ideas?
>
> I have a cairo_surface_t and draw on it.  And I copy it on gtk window
> when gtk wants so.
> I don't scale fonts explicitly.  Scaling is done implicitly by compositor,
> gtk, and cairo.
>
> My guess:
> cairo_surface_t is bitmap.
> On 1x, cairo_surface_t has non-scaled texts, and it is drawn on
> gtk window as is.
> When I move it to 2x, cairo_surface_t is drawn on gtk window
> at double size.  It is blurry, because cairo_surface_it is bitmap.
> When I resize it, I recreate cairo_surface_t of logical size.
> When that, cairo_surface_t is double size implicitly.
> cairo_surface_t has 2x scaled texts.  It is not blurry, because
> fonts are vector graphics.
> It is drawn on gtk window as is.
>
> Maybe, I need to recreate cairo_surface_t when monitor
> is changed.  I looked for such a signal but nothing found.
>
> --
> Yuuki Harano
>

[-- Attachment #2: Type: text/html, Size: 2632 bytes --]

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Yuuki Harano]

On Wed, 1 Dec 2021 10:20:41 -0500,
	Fred Fu <moonsolo@gmail.com> wrote:
> How do GTK applications handle this situation?
> 
> Does each gnome app deal with their windows moving among displays of scale
> factors on their own?
> 
> Or do they just delegate the dirty job to GTK or other lower-level
> mechanisms?

Switching scale factor among display is usually done by gtk.
Usual applications create cairo_surface_t(bitmap), use it for a short
time, and destroy it.  When creating it, scaling factor is reflected.

Pgtk emacs create cairo_surface_t, use it for a long time for cost and
algorithms, and scaling factor is not reflected until recreation.

-- 
Yuuki Harano

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Yuuki Harano]

I tried to keep track of scale factor using atimer.
I can see bluriness for a short time, but it is gone soon.
I think that is enough.

-- 
Yuuki Harano

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Alan Third]

On Thu, Dec 02, 2021 at 12:08:56AM +0900, Yuuki Harano wrote:
> Maybe, I need to recreate cairo_surface_t when monitor
> is changed.  I looked for such a signal but nothing found.

On the NS port whenever we create the context for drawing to the
bitmap we compare the dimensions/scaling. It's not ideal but it
doesn't seem to cause any noticeable slowdown. Perhaps PGTK can do
something similar?
-- 
Alan Third

bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

[Alan Third]

On Thu, Dec 02, 2021 at 10:09:54PM +0000, Alan Third wrote:
> On Thu, Dec 02, 2021 at 12:08:56AM +0900, Yuuki Harano wrote:
> > Maybe, I need to recreate cairo_surface_t when monitor
> > is changed.  I looked for such a signal but nothing found.
> 
> On the NS port whenever we create the context for drawing to the
> bitmap we compare the dimensions/scaling. It's not ideal but it
> doesn't seem to cause any noticeable slowdown. Perhaps PGTK can do
> something similar?

But then, having said that, I've just remembered we also call
expose_frame when the scale changes. That may not be possible if
there's no signal to let you know.
-- 
Alan Third