Wayland-Proxy Load Balancer Helping Firefox Cope With Wayland Issues

[indepe]

indepe The application could be using a software cursor.

As far as the wayland application itself is concerned, it is a software cursor. Then it depends what the compositor and other software/hardware does with it.

But I still think "frozen app cursor + hourglass" better communicates to the user what's going on in that case.

Yes.

[indepe]

If you restrict you self to only the stable parts of the Wayland protocol most applications don't run.

Even that is irrelevant to our discussion. The protocol you quoted has nothing to do with the suggestion I made.

Current day Windows and Mac OS don't display the cursor for non responsive applications they just run a internal countdown timer when it hit zero application is absolute terminated. This is timer between 0.5-7 seconds. Macos allows the value to be configured shorter and longer than Windows.

Wayland compositor disconnecting applications does not equal terminating applications. What going on is the Wayland applications are basically choosing to commit suicide when they lose their connection. Wayland robustness says the application instead of choosing to die when lost connection to Wayland compositor instead can choose to reconnect.

Something for application that being non responsive wayland compositor could choose to leave it last output on screen after it been disconnected from the Wayland compositor for a time. This is the major catch there is no need to maintain a connection that not actively in use.



Exactly the problem. Windows and Mac OS stopped doing this due to the double cursor problem. So when those platforms stop doing due to confusing users kind of makes sense to stop doing this as well.

Big reasons why Wayland compositors want to disconnect non responsive applications is free up resources on the compositor side.

Lets say you have a application that by design keeps up with the Wayland event buffers most common time it will come non responsive is when the application is terminating. Yes Wayland compositor taking application as being non responsive as that the application is terminating is right 95% of the time so allows early freeing of resources. If the application has Wayand robustness coded in in the 5% the compositor is wrong the application reconnects anyhow and as long as Wayland compositor kept where the windows were so can put the back the user mostly will not notice.

Big reason why Firefox and other applications are noticed is no Wayland robustness code so they die instead of reconnecting. Lack of Wayland robustiness also means firefox will not cope with kwin restart on kde. Please note the KDE developer working on Wayland robustness offered to help Firefox implement it but then firefox developer turned him down because they said firefox state saving code was good enough.....

I don't care anymore, if you keep misrepresenting or not understanding whatever I say, and then start ignoring it. I'm done duscussing this with you.

[Artim]

Yes, instead we use pipewire as a spacegoat to nullify whatever Wayland stack does to prevent us to freaking screen capture with OBS.

Why is that better?

How stupid are you? Wayland literally just made an API for screenshots and screen recordings with the condition the user must allow it and be able to select what is to be recorded, so no app can just spy with no knowledge of the user. Pipewire is just the first implementation that other apps can use to access that API.

And I am perfectly capable of screen capturing a Wayland session with OBS. They have added pipewire support at least a year ago. I don't know if they default to Wayland, otherwise if pipewire screen capture doesn't show up for you then you know now how to solve that issue. A quick googling of literally under 1 min would have given you dozens of pages giving you that explanation. But no, you prefer ranting some nonsense and spread lies.

[Artim]

I don't give a flying fuck what you call them. I only care how they work or actually do. They aren't even close to the "in-kernel filesystem drivers".

Nobody claimed anything different. It was merely to prove your lie about "drivers can only run in kernel context" wrong. There are many thing in Linux called a driver. So learn your fucking vocabulary.

You are also called a human being by society, but that's just not to hurt your feelings. You definitely have a completely different description than that in reality.

Sure, but one can only hope you aren't. I certainly don't want to share a common species with something as dumb as you.

Here's a simple question for you: Why is ntfs-3g a driver but stuff like unionfs is not, huh? They both use FUSE. Both are userspace and don't have direct access to hardware, either.

Well, first of UnionFS itself obviously can't be the driver as that's the name of the file system. NTFS-3G is the name of the FUSE driver implementing the NTFS file system. As it seems, the name of the FUSE driver for UnionFS is simply "unionfs-fuse". But of course, that's too difficult for a moron like you to understand, I see...

[oiaohm]

As far as the wayland application itself is concerned, it is a software cursor. Then it depends what the compositor and other software/hardware does with it.

No this is wrong and that you problem.

wl_pointer_set_cursor Wayland application does not treat this as a software cursor. This is a compositor rendered cursor that may be hardware accelerator-ed.

Software cursor can rendered by the application itself straight on to it own output buffer of the application. SDL applications support rendering cursor themselves or using host provided interfaces same with wine/proton by the way.

indepe its one of the things that makes mouse cursors such a pain. Application can render it own mouse cursor or use host provided primitives. Now a application rendering it own mouse cursors will tell the host mouse cursor to be nothing. So wl_pointer_set_cursor will be told the cursor is nothing. But the user will still be seeing a mouse cursor inside the application because the application rendering it. This is not the ideal way of doing things but that application developers for you.

The protocol you quoted has nothing to do with the suggestion I made.

I see why you say this now. You have the incorrect presume that application don't render their own mouse cursors and the trouble that causes. You presume application always use items wl_pointer_set_cursor the reality that don't and different extensions have been added to the wayland protocol to help out applications that render their own pointer.

Applications most likely to end up will filled event ques are most likely to be self rendering the mouse cursor as well. This is what makes dealing with this problem more complex. There is a reason why Microsoft and Apple stopped doing the display waiting mouse cursors and it what application developers have done and what we have to live with.

[indepe]

No this is wrong and that you problem.

wl_pointer_set_cursor Wayland application does not treat this as a software cursor. This is a compositor rendered cursor that may be hardware accelerator-ed.

Software cursor can rendered by the application itself straight on to it own output buffer of the application. SDL applications support rendering cursor themselves or using host provided interfaces same with wine/proton by the way.

indepe its one of the things that makes mouse cursors such a pain. Application can render it own mouse cursor or use host provided primitives. Now a application rendering it own mouse cursors will tell the host mouse cursor to be nothing. So wl_pointer_set_cursor will be told the cursor is nothing. But the user will still be seeing a mouse cursor inside the application because the application rendering it. This is not the ideal way of doing things but that application developers for you.



I see why you say this now. You have the incorrect presume that application don't render their own mouse cursors and the trouble that causes. You presume application always use items wl_pointer_set_cursor the reality that don't and different extensions have been added to the wayland protocol to help out applications that render their own pointer.

Applications most likely to end up will filled event ques are most likely to be self rendering the mouse cursor as well. This is what makes dealing with this problem more complex. There is a reason why Microsoft and Apple stopped doing the display waiting mouse cursors and it what application developers have done and what we have to live with.

That's at least getting to the point, however it is the other way around: wl_pointer_set_cursor is the API that allows an application to render its own cursor.

There is another protocol for setting the cursor in testing/staging: "wp_cursor_shape_manager_v1" aka "cursor_shape_v1".
However this protocol is specifically for using an enumerated, preexisting cursor shape.

In both cases, the cursor shape/buffer/surface is sent to the compositor, and the compositor is in a position to either use this shape, or instead display a different one, if it wants to. (Currently it always uses the one provided by the application).

[ssokolow]

Obviously not. Why should they, users don't have interest in that. The customizations are done by the distributors of chromium based browsers. So of course, you could do the same if you can't find a browser capable of showing the UI you want. That's your problem then. But about 99 % of all browser users don't even waste a thought about such things, so nobody saw the necessity to enable such customization for other browsers.

*psst* Nobody tell this guy that there there are entire communities making and sharing userChrome.css customizations to cover things formerly supported by Firefox's XUL-based legacy extensions, which are the heartland of Firefox's remaining marketshare.

[oiaohm]

That's at least getting to the point, however it is the other way around: wl_pointer_set_cursor is the API that allows an application to render its own cursor.

No wrong here.. wl_pointer_set_cursor provides the compositor a surface with the cursor the applicaiton wants to be rendered where the mouse is by the compositor.

In both cases, the cursor shape/buffer/surface is sent to the compositor, and the compositor is in a position to either use this shape, or instead display a different one, if it wants to. (Currently it always uses the one provided by the application).

What you wrote here is right.

Now I am writing a cross platform application as a common foolish programmer the cursor format I have chosen does not match wl_pointer_set_cursor or cursor_shape_v1 what do I do. That right render the mouse cursor myself and tell the platform to render nothing. Is this going to be CPU cycle expensive hell yes is this going to increase odds of being non responsive to the OS hell us do I can no I tell my users to buy a bigger CPU.

There is a old saying you can lead a horse to water but you cannot make it drink. You can provide API after API to have something other than the application itself render the mouse cursor and you still will have applications rendering their own mouse cursor internally.

https://discourse.libsdl.org/t/sdl-opengl-fast-mouse-cursor/12166/5

This is from 2005. Its not a new thing for application developers to get in there head that rendering the mouse cursor inside the application will be better than using the platform cursor rendering because it will so called be faster/better for the game or application when this will never be true.

indepe this is like application developers using spinlocks instead of futexes.

The reality is you have to live that application developers that make programs with poor event loops are also likely to do many of these other bad things.

indepe basically you are being overly optimistic. Like it or not applications will exist with poor event loops that render their own mouse cursor on to the applications own output buffer and straight up refuse to use any form of compositor assistance to draw their mouse pointer.

This problem of applications rendering their own mouse cursor is true for Windows, MacOS, X11 and Wayland. This is a platform neutral problem.

https://discourse.gnome.org/t/pointe...wayland/9197/3 yes here 2022 another group of developers this time with wayland working out how to have applicaiton render cursor themselves and not use the API you were pointing to.

Remember the protocol I pointed to and you dismissed as its unstable. You find over and over again people writing you want to software render mouse cursor from application and not using the wayland compositor rendering use the protocol extension I pointed to so they can pull it off.

So any application using Pointer constraints extension to protocol you have to presume is self rendering the mouse cursor.

I am a little bit more aware how the applications developers avoid doing the right things. Wayland compositors have to deal with applications miss behaving to some extent and this limits what compositor can and cannot do.

This is why its not as straight forwards as hey I will display a waiting mouse cursor because this results in user seeing 2 or more mouse cursors on screen(yes depend on how many programs they have badly coded and stuck)

We would all like if applications had correctly working events loops and always use compositor mouse pointer rendering but the reality this is not the case.

Yes those programmer wanting todo things the wrong way will do all kinds of insanity and have to have failure after failure before they will code stuff the right way.

[indepe]

No wrong here.. wl_pointer_set_cursor provides the compositor a surface with the cursor the applicaiton wants to be rendered where the mouse is by the compositor.

Uhh... of course. So what is wrong with what I wrote "here"?

What you wrote here is right.

Now I am writing a cross platform application as a common foolish programmer the cursor format I have chosen does not match wl_pointer_set_cursor or cursor_shape_v1 what do I do. That right render the mouse cursor myself and tell the platform to render nothing. Is this going to be CPU cycle expensive hell yes is this going to increase odds of being non responsive to the OS hell us do I can no I tell my users to buy a bigger CPU.

Surely this is a hypothetical scenario. What you do is this: You copy your pixel data from whatever format you have into a wl_buffer, attach this buffer to a wl_surface, and pass this wl_surface as a parameter to wl_pointer_set_cursor.

There is a old saying you can lead a horse to water but you cannot make it drink. You can provide API after API to have something other than the application itself render the mouse cursor and you still will have applications rendering their own mouse cursor internally.
....
This is from 2005. Its not a new thing for application developers to get in there head that rendering the mouse cursor inside the application will be better than using the platform cursor rendering because it will so called be faster/better for the game or application when this will never be true.

There must be something very simple you are not understanding, but I can't figure out what it is. Applications that render their own cursor image can use wl_pointer_set_cursor to send this image to the compositor, and the compositor will display it.

How is that difficult to understand?

...
Like it or not applications will exist with poor event loops that render their own mouse cursor on to the applications own output buffer and straight up refuse to use any form of compositor assistance to draw their mouse pointer.
....

Applications can draw their own mouse cursor without assistance from the compositor. But then they send this image to the compositor so that the compositor displays it on the screen (with or without hardware assistance).

In Wayland applications do not have direct access to the screen itself, it all goes via the compositor. (Maybe except, I don't know, full screen games that by-pass the standard Wayland architecture).

EDIT:
See my next post.

[indepe]

This problem of applications rendering their own mouse cursor is true for Windows, MacOS, X11 and Wayland. This is a platform neutral problem.

https://discourse.gnome.org/t/pointe...wayland/9197/3 yes here 2022 another group of developers this time with wayland working out how to have applicaiton render cursor themselves and not use the API you were pointing to.

Remember the protocol I pointed to and you dismissed as its unstable. You find over and over again people writing you want to software render mouse cursor from application and not using the wayland compositor rendering use the protocol extension I pointed to so they can pull it off.

Wait, I figured it out. You are not talking about drawing a cursor image, you are talking about an application drawing something that looks like a cursor, but isn't a cursor in the Wayland sense, and they are drawing it into the window surface.

Well, those simply won't get a special "delay" cursor image. They are on their own in that regard.