Bug 424434

>This breaks existing web content in the case of a browser, 

Can you give an example?
How is that content going to work on wayland?

> Can you give an example?

The test case I provided in the report is one.

But if you mean something more "meaningful" than displaying x and y coordinates for the sake of it, I think this one will break as a consequence of the issue (though I haven't tested yet): http://stewd.io/pong/

> How is that content going to work on wayland?

I have no idea. I don't know what wayland is. All I know is the test case in the report works on most browsers on Windows, Mac OS, and Linux with Gnome, Unity, and Cinnamon. Plasma is the only environment where I've ever seen it fail.

>I don't know what wayland is.

Upcoming replacement for X.
No windows will know their own position. Regardless of the desktop environment.

Firefox on gnome running wayland would undoubtedly hit the same issue.


---

I did look this up, the code in kwin is very deliberate about deferring the synthetic configure events on moves.

a04e9cbc6f0547aa10ab8ce457ef0aa008d72997

 Optimize away XMoveWindow() calls in the common click-and-drag case
    
    This implements an optimization similar to one in compiz which defers updating
    the backing X window during a window move until the move is terminated. This
    helps alleviate some choppiness when using composite + vsync.
    

It's a trivial one line change to make but I'm relunctant to make a change that would flood all clients with pointless configure events without hearing a better use-case than "browser pong". Especially if they're going to have to be broken soon anyway.

> I'm relunctant to make a change that would flood all clients with pointless
> configure events

"Pointless" according to what criterion?

I'm not sure we really need "events", though. In the case I'm considering, the application is not listening for an event (at least from the point of view of the JavaScript code), it's actively querying for a given property when it needs it, and you are returning an obsolete value.
Now I don't know if the only way for the application to know its configuration is to listen for events and store the values when they change. IF that is the case and it impacts efficiency (that is, IF an application has no way of querying for a given window parameter at a given time without "subscribing" for being notified of events, AND being flooded by those events without doing anything more than storing the values it needs to read later is costly), then it means the overall architecture is poorly designed.


> without hearing a better use-case than "browser pong"

What criteria does a use case need to meet to be good enough for you?
Does it need to be "useful"? Where do you draw the line between useful and not useful? Does it need to save lives? (note that I didn't create "browser pong", I just spent a couple of minutes to look for a random use case because you asked)

What even is a use case? What if the use case is something genius that neither you nor I have even thought about yet? You shouldn't ask for a use case for a feature. The mere thought of a feature should be enough to require its existance. To me, when I can describe a feature with words, that automatically translate to a use case: "Someone might want to do that", that's it.
And if the feature has existed for the last 20 or 30 years in every major OS, then before you take it away, you need to be able to prove that a use case can't possibly exist (which is usually impossible, that's why you usually just don't remove a feature that has existed for ages). Unless of course you gain something huge by removing it, but that's obviously not the case here.

That "flooding" that you are afraid of is already happening in all the other major desktop environments, and I don't see them become slow or unresponsive when I move windows around. If KDE did, then probably that would mean there's an issue elsewhere that needs addressing.


> Upcoming replacement for X.
> No windows will know their own position

Wow. Looks to me like someone had a really, really stupid idea there.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Not sure why this was set to NEEDSINFO.

The code was changed deliberately. If it breaks something that isn't an abuse of windows to begin with we can change it.
But so far it seems we would just be creating overhead and achieving nothing tangible.

>I'm not sure we really need "events", 

The discussion needs to happen in the form of the X11 wire protocols. How chrome exposes this to your application isn't very relevant.

> But so far it seems we would just be creating 
> overhead and achieving nothing tangible.

If making it *possible* for an application to know its window's position while moving creates overhead even for those applications who never take advantage of it, then something in the system is very badly designed and that needs to be fixed. If only those applications who actually "query" for their window position will suffer from the overhead (and if the overhead is not bigger than it needs to be), then it's up to the applications whether or not to use the feature.

> If it breaks something that isn't an abuse of windows to begin with we can change it

What is "an abuse"?? 

You can't just say some use case is an abuse because you hadn't thought of it or because it's useless to you. Any use of windows (or of any other feature) should be assumed to be legitimate unless you can prove the contrary.

You should approach it the other way around: if it breaks something (and it does, I have already provided an example, no matter how stupid), then it needs to be changed, *unless* you can prove that every single use case that gets broken, is an abuse. Which means:
1. you need to be able to give a very, very precise definition of what you mean by "an abuse" in the first place
2. you need to be able to argue not only that the particular case that is known to get broken is an abuse, but that ANY possible use case that you may have not thought of yet, is also an "abuse".

And yes, that's basically impossible, which is precisely my point: the mere fact that I can make up a use case, no matter how stupid, basically means it has to be supported. There's (almost) no such thing as an "abuse", or a not-good-enough (i.e. "better than Browser Pong") use case.



Consider this other use case:

A window with a background that acts like....... well, a literal window. That is, a window with a "virtual background" image that is anchored to the screen, and has the size of the entire screen, regardless of the position and size of the window. You move the window, you move the "hole" that lets you see the background.

Why would I want that? For the sake of it. Because it's aesthetically pleasing (to someone). That's a good enough reason as far as the OS needs to be concerned.



Now, regarding the supposed overhead. EVERY other operating system and every other major desktop environment except for Plasma has this. As far as I know, they don't become sluggish or less responsive when you move windows around.