7 ms·

What could be the reason behind this? Asking as a noob.

beowulfey 6y ago
I personally don’t know, but most likely when you are not forced to think about memory, efficiency, etc... most people just don’t. So if you aren’t actively developing on those lightweight systems your code won’t run efficiently on them.
- Flex247A 6y ago
  I guess that explains why Electron based apps don't feel as snappy as native ones.
p_l 6y ago
Part of it is toolkits throwing sometimes multiple megabyte bitmaps to draw, which starts to have problems the moment you don't have a zerocopy, gpu accelerated method to draw them. The old core protocol approach extensively used optimized graphic operations on the server side, with clients sending things like "draw me a rectangle/fill a rectangle/draw a bunch of lines" etc. - today you're going to get pretty big bitmap (especially with high dpi). It's the same problem that mobile devices faced, and is related to a lot of issues on how android devices were "janky" (and related to the various hacks that Apple did to make sure your application wasn't capable of overstressing the early iPhones - cause just displaying basic UI was close to doing that.)
goatinaboat 6y ago
What could be the reason behind this? Asking as a noob Abstractions piled on top of abstractions. Something that might have been 5 function calls deep on either side with a carefully crafted packet in the middle is now 100s on each side. We have a culture that prizes programmer happiness above all and this means everyone thinks "this is a mess, I'll put my own layer on top to make it nice, then work above that layer". Repeat 100 times and now you have processors literally 2000 times faster that struggle to even keep up with keypresses. But what noone wants to admit, is that it's messy because the problem domain is messy and sometimes you just have to live with the mess and get some real work done. The programmers of old understood this.
- Spooky23 6y ago
  Exactly. There’s no customer, so the product is a nerd carnival that delivers whatever the developers want.
- adwn 6y ago
  Okay, nice rant, but are too many layers of abstraction the actual cause for Wayland's (alleged?) slowness compared to X? From what I understand, no.
Fnoord 6y ago
The compositor is evil [1] [1] https://news.ycombinator.com/item?id=24466929 https://news.ycombinator.com/item?id=24466929
pfortuny 6y ago
When a window bar needs a gradient, you are starting to stress the graphics engine... And that is just a simple bitmap (or not)...
- pmarin 6y ago
  http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part-15----Gradients.html http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part...
  - pfortuny 6y ago
    Wow thanks. I was saying that just in order to show the most basic example.
Const-me 6y ago
Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. Windows is using it since Vista. When done right, gradients mentioned in other comments are free, GPUs have hardware to interpolate values (such as colors) across vertices of triangle, for free. Many other effects are either free or very cheap. Engineering-wise it's really hard. Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical). The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens. I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.
- danaris 6y ago
  > Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. It's great for the common desktop case. It's not as great for some other cases in which Linux is the preferred platform (headless servers, repurposed old hardware, etc). The problem isn't, of course, that there exists a solution for this on Linux. It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.

I personally don’t know, but most likely when you are not forced to think about memory, efficiency, etc... most people just don’t. So if you aren’t actively developing on those lightweight systems your code won’t run efficiently on them.

Flex247A 6y ago
I guess that explains why Electron based apps don't feel as snappy as native ones.

p_l 6y ago

Part of it is toolkits throwing sometimes multiple megabyte bitmaps to draw, which starts to have problems the moment you don't have a zerocopy, gpu accelerated method to draw them. The old core protocol approach extensively used optimized graphic operations on the server side, with clients sending things like "draw me a rectangle/fill a rectangle/draw a bunch of lines" etc. - today you're going to get pretty big bitmap (especially with high dpi). It's the same problem that mobile devices faced, and is related to a lot of issues on how android devices were "janky" (and related to the various hacks that Apple did to make sure your application wasn't capable of overstressing the early iPhones - cause just displaying basic UI was close to doing that.)

goatinaboat 6y ago

What could be the reason behind this? Asking as a noob Abstractions piled on top of abstractions. Something that might have been 5 function calls deep on either side with a carefully crafted packet in the middle is now 100s on each side. We have a culture that prizes programmer happiness above all and this means everyone thinks "this is a mess, I'll put my own layer on top to make it nice, then work above that layer". Repeat 100 times and now you have processors literally 2000 times faster that struggle to even keep up with keypresses. But what noone wants to admit, is that it's messy because the problem domain is messy and sometimes you just have to live with the mess and get some real work done. The programmers of old understood this.

Spooky23 6y ago
Exactly. There’s no customer, so the product is a nerd carnival that delivers whatever the developers want.
adwn 6y ago
Okay, nice rant, but are too many layers of abstraction the actual cause for Wayland's (alleged?) slowness compared to X? From what I understand, no.

Fnoord 6y ago

The compositor is evil [1] [1] https://news.ycombinator.com/item?id=24466929 https://news.ycombinator.com/item?id=24466929

pfortuny 6y ago

When a window bar needs a gradient, you are starting to stress the graphics engine... And that is just a simple bitmap (or not)...

pmarin 6y ago
http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part-15----Gradients.html http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part...
- pfortuny 6y ago
  Wow thanks. I was saying that just in order to show the most basic example.

Const-me 6y ago

Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. Windows is using it since Vista. When done right, gradients mentioned in other comments are free, GPUs have hardware to interpolate values (such as colors) across vertices of triangle, for free. Many other effects are either free or very cheap. Engineering-wise it's really hard. Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical). The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens. I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.

danaris 6y ago
> Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. It's great for the common desktop case. It's not as great for some other cases in which Linux is the preferred platform (headless servers, repurposed old hardware, etc). The problem isn't, of course, that there exists a solution for this on Linux. It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.