Wayland

[hiro]

pq: sorry for stealing you all this time you needed to insult me.

i'm trying to question my opinion, which is: wayland brings no advantage to my setup.

I didn't have noticeable lag when I moved windows in windows 95, and i don't have any annoying lag in fl_topside either.

If it needs gnome3 to replicate or "compositing window managers" then it seems I'm safe for now, cause i'm not aware of any such things existing in my computer.

[hiro]

To quote freedesktop.org: "The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases."

It seems to me that you, like most freedesktop related projects don't understand the definition of minimal.
You not understanding the benefit of software rendering also suggests you have no idea what tinycorelinux minimalism is about.

[pq5190362]

I didn't have noticeable lag when I moved windows in windows 95

But you had tearing. Lots of it. And repainting artifacts. Lots of them. Which is true for all versions of Windows prior to Windows Vista. Windows Vista introduced DWM (Desktop Window Manager), which is a compositing window manager, which got rid of all that mess which is tearing and repainting artifacts, but read for yourself:

https://blogs.msdn.microsoft.com/greg_schechter/2006/03/19/dwms-use-of-directx-gpus-and-hardware-acceleration/
https://msdn.microsoft.com/en-us/library/windows/desktop/ff684179(v=vs.85).aspx

and i don't have any annoying lag in fl_topside either.

But you have tearing. See above.

If it needs gnome3 to replicate

It does not need GNOME 3 (which comes with Mutter, which is a compositing window manager). And, as already mentioned, Mutter @ X is actually not that bad in this regard. There are other X compositors which are worse.

With Wayland compositors (such as Mutter @ Wayland or Weston), those issues are gone.

or "compositing window managers" then it seems I'm safe for now, cause i'm not aware of any such things existing in my computer.

You almost certainly will experience screen tearing and repainting artifacts when you're not using a compositor. In theory, it would be possible to get a tear free experience with certain DDXs, such as xf86-video-intel and xf86-video-ati/xf86-video-amdgpu, since they have a "TearFree" option, but in practice, that doesn't work so well...

By the way, here's an interesting thread about the whole topic:

https://www.reddit.com/r/linux/comments/5f4ul3/does_wayland_actually_eliminate_tearing/daifis8/

 

[nitram]

Wayland is interesting, i've never used it, on paper exciting. Does Wayland only run Gnome, KDE or Weston. What about all the great WMs, they need xwayland added to the mix? That's my understanding, if so 'an X server running on top of wayland' sounds bloated and complicated. There are probably lots of old Tiny Core systems with software rendering only, please don't exclude these systems at the expense of something less proven, still in active development.

Great Wayland made it into *Core, default probably not for many years anyway. FWIW old hardware with the right software in present TC does not lag or tear. Running modern Gnome would cripple this hardware, it's easier to avoid the bloat than figure out a workaround.

pq5190362 If you're serious then provide numbers and a test ISO, as already suggested. To be default it needs to work across all hardware and provide the same functionality or better than presently offered. Creating a  TC respin is an alternative, develop it over a few months and release something fantastic.

[hiro]

good. i only care about lag. i don't care about tearing. that's why i asked for proof of your first claim that this helps improve lags.

[curaga]

pq, your behavior towards others is insulting, and how you sprinkle smileys on top of demands is making me consider a temporary ban. That is no way to behave in this community.

So, you're arguing without knowing the numbers...

I know quite well it's lots more.
Mesa > 10mb (just drivers, llvm and libs not included)
llvm-lib 5.6mb
KMS 1.5mb
...

All components not currently needed in the base.

And how's that an issue? Intel/AMD/NVIDIA hardware, they are all supporting KMS, at least with the open source drivers.

Much of the hw we support does not have any KMS drivers. And for the hw that does, we don't want to force users to install the 1.5mb support.

Which Intel/AMD/NVIDIA hardware supports out of the box when using the open source drivers as far as I know.

Indeed it does. At the cost of >30mb space.

I doubt software rendering is required when using open source drivers on Intel/AMD/NVIDIA hardware, which is probably being used by the majority of users in the (almost) year 2017  .

It appears you aren't familiar with our supported hw base. We support everything from 486 up, having minimal and embedded targets, while being suitable for VM's, appliances and small servers. Desktop use is not discouraged, but for a user with 2017 hardware looking for a modern experience, there are other distributions such as Ubuntu that might suit them better.

[Juanito]

Start GNOME 3 @ X (with Mutter as the hardware accelerated compositing window manager incl. Vsync). Now open a window and place the mouse cursor on the window titlebar and click and hold the left mouse button and move the mouse around to move the window around. As you can see, the mouse cursor is faster than the window movement, i.e. there's some kind of input/rendering/drawing lag.
...
Start GNOME 3 @ Wayland and do the same (i.e. move a window around). You will see that the mouse cursor and window movement is in perfect sync and it feels much less laggy and rock solid.
...
The same is also true for running Wayland @ Weston.

Entirely unscientific testing, but with corepure64 if I start gnome 3 and whizz a gnome-terminal window around in circles, it does not look any different to starting weston with the drm backend and whizzing a weston-terminal window around in circles.

[Rich]

Hi hiro

good. i only care about lag. i don't care about tearing. that's why i asked for proof of your first claim that this helps improve lags.

For what it's worth, with my hardware I've found that anything terminal based benefits greatly by setting  Aterm*transparent
in  .Xdefaults  to  false.

[Juanito]

It looks very much like the mutter wayland backend will not compile without systemd, in which case wayland cannot be used with the corepure64 version of the gnome desktop.

[pq5190362]

pq, your behavior towards others is insulting

No, it's not. This...:

i.e. support their crappy feature request

is what's insulting.

and how you sprinkle smileys on top of demands is making me consider a temporary ban.

If you think that smileys are something negative, then, well, yeah, maybe you should go ahead... But feel free to delete the entire account then instead of just banning it. But please consider banning hiro first.

Desktop use is not discouraged, but for a user with 2017 hardware looking for a modern experience, there are other distributions such as Ubuntu that might suit them better.

Then I ask myself why Juanito seems to prefer getting the full fledged GNOME 3 up and running instead of the much more minimal Weston.

[Juanito]

gnome is already up and running with X, so I thought (wrongly) that adding wayland support would be easy.

As far as I know, weston is just a test vehicle - as mentioned above, I got it working, but it doesn't really do much out of the box.

[pq5190362]

As far as I know, weston is just a test vehicle - as mentioned above, I got it working, but it doesn't really do much out of the box.

Well, I don't see how FLWM is doing more than Weston. Anyway, there are quite a few Wayland compatible compositors / window managers / desktop environments, the Arch Linux Wiki has a list of them, see:

https://wiki.archlinux.org/index.php/wayland#Window_managers_and_desktop_shells

You can test out a few of them by running RebeccaBlackOS:

https://sourceforge.net/projects/rebeccablackos/

[Juanito]

weston will be available in the corepure64 8.x repo

[hiro]

@pq5190362 please stop misquoting me in this out of context way.

[pq5190362]

It looks very much like the mutter wayland backend will not compile without systemd, in which case wayland cannot be used with the corepure64 version of the gnome desktop.

May I ask how you came to the conclusion that systemd is required to build Mutter with Wayland support?