Winit/WR doesnt works well on hyprland

[declantsien]

Issue created based on comment

I run hyprland mostly and it's definitely more of a problem than e.g. weston. E.g. it sends lots of resize events, so the queue needs to be filtered before processing them, or they take forever to process (and occasionally hang).

It should be specific when using winit as windowing implementation.

[2e0byo]

Actually this one is also a problem on tao.

[declantsien]

it sends lots of resize events

There used to be a recursive loop of resize in the code-base. I think I've fixed that in latest master.
Can you confirm? @2e0byo

[2e0byo]

Resize events are fixed, thanks. There's still a problem---I think locking---with the event loop though. E.g. if you mouse off the window it flickers and sometimes blanks entirely; the same happens if you change size too much. I need to confirm that these are Hyprland specific. It's possible to get into a state where the window simply doesn't redraw at all. It should just be a matter of working out in the debugger where the window gets cleared and then what blocks it from redrawing. (Ideally ofc we the window should only get cleared when we're ready to swap a new buffer into it.)

A side effect of fixing the resize loop is that windows open up with the wrong scale/size much more frequently on Hyprland, but I think this is again just a matter of finding out where the event is getting stuck. It may be that the initial size event comes too quickly to get handled at all.

I'll fire up GDB this weekend unless it's been magically solved by then like all the other things I was going to fix :D

[declantsien]

Resize events are fixed, thanks. There's still a problem---I *think* locking---with the event loop though. E.g. if you mouse off the window it flickers and sometimes blanks entirely; the same happens if you change size too much.

I assumed you are using TAO with glutin then. I believe this can't be avoid. Since glutin is using the native Wayland window OpenGL context, and TAO(GTK) window is also using Wayland window. I think they are fighting over each other. That why I add `--with-wr-gl=gtk3` for tao, using GTKs gl_area. So there is no conflicting.

A side effect of fixing the resize loop is that windows open up with the wrong scale/size much more frequently on Hyprland, but I think this is again just a matter of finding out where the event is getting stuck. It may be that the initial size event comes too quickly to get handled at all.

Yeah, you are right. The default `scale_factor()` from Window is 1. Then some font opened with this scale_factor 1, later it got populated with real value(BTW, the `ScaleFactorChanged` is never fired for both winit and TAO). Usually a resize of the window would match the them together. Like we talked before, there is a better way: We always set scale to 1 for font and Emacs frame size, send to Emacs redisplay for glyph strings. Then applied the scale when draw. But that is some refactoring work.

[2e0byo]

I assumed you are using TAO with glutin then. I believe this can't be avoid. Since glutin is using the native Wayland window OpenGL context, and TAO(GTK) window is also using Wayland window. I think they are fighting over each other. That why I add --with-wr-gl=gtk3 for tao, using GTKs gl_area. So there is no conflicting.

Ah, that makes sense. I've started a rebuild and will test. TBH I'd like to work on the winit port again but haven't the time atm (if we're going to use gtk (tao) we might as well use pgtk). Having the windowing entirely in rust would fix a lot of the random segfaults you can get with the FFI into gtk.

(BTW, the ScaleFactorChanged is never fired for both winit and TAO).

Drat. I was assuming that would handle it.

Like we talked before, there is a better way: We always set scale to 1 for font and Emacs frame size, send to Emacs redisplay for glyph strings. Then applied the scale when draw. But that is some refactoring work.

I do think this is the right way long term. It should also reduce memory/cpu usage on Emacs's size. But it will mean that non-vector graphics gets rasterised. Presumably though things like the glyph objects will handle being multiplied by a scale? (pdf-view already handles this by sending an image multiplied by the scale factor, so there's no reason to worry about it I think.)

Apparently firefox takes this approach, so I guess we should have a look at the source to see how they do it.

[declantsien]

2e0byo ***@***.***> writes:

I do think this is the right way long term. It should also reduce memory/cpu usage on Emacs's size. But it will mean that non-vector graphics gets rasterised. Presumably though things like the glyph objects will handle being multiplied by a scale? (`pdf-view` already handles this by sending an image multiplied by the scale factor, so there's no reason to worry about it I think.) Apparently firefox takes this approach, so I guess we should have a look at the source to see how they do it. -- Reply to this email directly or view it on GitHub: #494 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

Emacs PGTK uses this way too. Since our `draw_canvas.rs` expecting the glyph size that will been draw on the screen now. I simply scaled up PGTK Emacs frame size. As for memory/cpu usage, I now only got high cpu/memory when launch. And it will drop to normal level after some time. This happens with scripts using elisp with normal Emacs too.

[2e0byo]

the tao/glutin thing is indeed the cause of flickering. I've updated the docs and merged the PR since it was trivial, but feel free to edit.

[declantsien]

2e0byo ***@***.***> writes:

the tao/glutin thing is indeed the cause of flickering. I've updated the docs and merged the PR since it was trivial, but feel free to edit. -- Reply to this email directly or view it on GitHub: #494 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

Looks good to me.

[declantsien]

Like we talked before, there is a better way: We always set scale to 1 for font and Emacs frame size, send to Emacs redisplay for glyph strings. Then applied the scale when draw. But that is some refactoring work.

I do think this is the right way long term. It should also reduce memory/cpu usage on Emacs's size. But it will mean that non-vector graphics gets rasterised. Presumably though things like the glyph objects will handle being multiplied by a scale? (pdf-view already handles this by sending an image multiplied by the scale factor, so there's no reason to worry about it I think.)

Apparently firefox takes this approach, so I guess we should have a look at the source to see how they do it.

I implemented it here #518. Would you like to give it a test?