4 ms·

I'm typing this from a wayland session of the GNOME 3.14 beta (via Fedora 21 Branched). While there are still some serious bugs, I have to say I am very impress

• mixmastamyk 12y ago
  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.
  • rayiner 12y ago
    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 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.
    • yarrel 12y ago
      Nope, not seen that. Sounds like resizing on a poorly written MacOS Classic application. Possibly it happens and my brain filters it out.
      • audidude 12y ago
        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).
        • silon3 12y ago
          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.
          • rayiner 12y ago
            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.
            • jiggy2011 12y ago
              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.
              • silon5 12y ago
                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).
    • mixmastamyk 12y ago
      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.
• Jasper_ 12y ago
  What serious bugs have you encountered so far? Let me know, as I need to fix them before release.
  • jmhain 12y ago
    I suspect many of the issues are actually problems with Fedora (it seems I have a mix of 3.13.9 and the previous release) but I'll list them anyway, just in case. * Apps are actually launching under xwayland by default. Everything segfaults if launched with GDK_BACKEND=wayland. * I use dvorak. Xwayland honors the setting but the shell is still qwerty. * Two-finger scrolling works in xwayland (though twice as fast as usual) but not at all in shell. * Restarting shell kills running apps and afterwards only Web will open. And it has the app menu and min/max button in the headerbar. * External monitor not recognized, works fine under X
• axaxs 12y ago
  Question if I may since you seem familiar with gnome. I use 3.12 and really enjoy it, but gnome shell (or mutter, or the js engine) seems to leak memory pretty badly. That is, if I mouse to the top left hot corner, then escape, I see its RSS increase, as probably expected. However, it increases each time I do this. I can get it to 500mb by doing nothing more than going into and out of the dash for a few minutes. In real use, after an eight hour day I see it anywhere from 700m to 1g rss. Any idea what's happening behind the scenes, or if this still happens in 3.14?
  • audidude 12y ago
    What happens if you run looking glass and perform a garbage collection. (<Alt>F2, lg<Return>, click on trash icon). If you see RSS drop significantly back down, there is a chance it will be fixed in the future. It's pretty difficult to let the JS engine know how big the resources are that are not in JS-land so that it can take things into account for a GC. (There are some patches related to this in bugzilla IIRC).
• pippy 12y ago
  Each time I've attempted to use Linux as my main OS it's always X11 that scares me off. Booting into console to edit xorg.conf gets tiring after a while, spending hundreds of dollars for graphics card that has more stable drivers, the general ancient 90's feel. I've tried it multiple times, but gave up each time.
  • 1_player 12y ago
    You may be surprised by the latest versions, then. I haven't edited xorg.conf in a long time (years?). And I'm using a power user oriented distro, Arch Linux.
  • TD-Linux 12y ago
    As long as you use the open source drivers, you'll be fine. And lucky for you, the cheapest graphics cards (Intel integrated and AMD) have the best open source support.
  • deleted 12y ago
    [deleted]
  • mercurial 12y ago
    Per default, you don't have xorg.conf anymore on modern distros. I have been in the "edit xorg.conf" boat as well, but there have been tremendous improvements since the bad old days.
  • donniezazen 12y ago
    Again this is very subjective. I have never had to mess with xorg. Things like Nvidia Optimus are obviously a tipping point of the problem.