Hacker News Reader

Comment by mixmastamyk | Hacker News Reader

I've been using Linux for two decades and not experienced the graphical glitches you speak of. Moving and resizing windows? Nope. Some infuriating compiz bugs, sure.

View on HN

You didn't notice in two decades that moving and resizing windows in Linux was an ugly affair plagued by graphical artifacts? I wrote this almost a decade ago and as far as I can tell it's still true today unless you use Wayland: http://www.osnews.com/thread?93850. Obviously a lot of pieces (graphics drivers, etc) have fallen into place since then, but it seems like ditching X was a necessary step to getting a clean, artifact-free experience.

Nope, not seen that.

Sounds like resizing on a poorly written MacOS Classic application.

Possibly it happens and my brain filters it out.

look closer. you mouse cursor will move ahead of the window. check out the Xorg mouse handler code. it performs the update in a signal handler while the rest of the window movement is in the normal path (which could be blocked by chatty Xlib clients).

That's normal and a feature. Mouse pointer is driven by hardware input and rendered independently (was a hardware overlay in the old days) and is soft realtime (hopefully). Because the window manager is a normal process, operating asynchronoysly, the window frame will lag a bit (depends on system load), and the app contents even more (this can't be avoided, even if the WM/compositor was realtime). Making the window frame wait for window content is broken by design.

Its not a feature, its an implementation artifact of the window frame being drawn by a separate process than the window contents. Its broken by design. OS X does it the right way, with the window contents and window frame being redrawn in lockstep and double-buffered so the user never sees partially drawn windows.

This is probably a legacy of X's network oriented history. If your window contents are being rendered by another computer on the end of a high latency connection you want to be able to reorganise your windows on screen without waiting for the other end to finish the reflow.

I assume that window contents are drawn to a buffer before being rendered on a modern system anyway. I can't remember the last time I saw partially drawn window contents.

It's not a historic artefact. You can't trust the app to render in time... (that's also why client side decorations are worthless).

But wouldn't that also hold for OSX/Windows?

Well, even if you assume the app will take too long to render, is it really worthwhile to render the "rest" of the window (pointer, frames, etc). The main reason you're working with a particular window is the content, not the chrome, so drawing the chrome asynchronously only serves to make things look weird, not actually get things done faster.

when i talked to keithp about this last year, he wasn't as enthused as you seem to be about the implementation. it was purely a side effect that causes people to think that Xorg isn't locked up when it actually is.

Nope, smooth here. But now that you mention it, resizing (only) is behind the cursor a bit. Honestly never noticed, I'm not in the habit of resizing my windows often enough for it to matter much.

Reply on news.ycombinator.com