Just in time: Wayland will let you turn off vsync

Just in time: Wayland will let you turn off vsync

Attached: 1561945067280.png (117x150, 6K)

Other urls found in this thread:

youtube.com/watch?v=Zsz7Shbnb9c
old.reddit.com/user/_Diablo2_
youtube.com/watch?v=Ux-WCpNvRFM
github.com/KhronosGroup/Vulkan-Docs/issues/294
wayfire.org/
twitter.com/SFWRedditImages

Thanks for fucking making a thread about it.

> Daily thread promoting the newest systemd tier FOSS shitshow called Wayland
Who cares.
Two mandatory buffer swaps per update means Wayland will suck at latency for ever.

just did a latency test with my canon and sway is more responsve than my xfce setup
my methodology is flawled tho
whats a trustyworthy linux news website that could do this for /us/

We could ask the phoronix guys.
All you need is an Arduino acting as keyboard connected to a photodiode measuring the time difference.
Then we will see once and for all if the concerns of autists are even justified.

X is absolute, unadulterated, pure fucking garbage, and I wholeheartedly welcome the advent of Wayland, or literally any other display server/protocol that comes along and takes X to the fucking gallows once and for all.

The model as a whole is extremely outdated, visibly inefficient, insecure, and it such a fucking mess of spaghetti code and extensions and life support that only a few people on the planet still understand how to actually maintain it. Their opinion on X? "Kill it with fire, please."

For a group of people that love to lambaste Windows users for having "babyduck syndrome", I've never seen more babyducks when it comes to the retards peddling the "x-xorg just werks" shit and spreading dumbfuck FUD about Wayland. (Of course, in all fairness, it doesn't help when all the distros out there wanted to be the first kids on the block to use Wayland and started pushing it out before it was 100% ready, leading to the average retarded joe to swear off of it.)

Similarly, for a group of people that jerk themselves off over software minimalism, there sure are a lot of people that love to suck the bloated dick of X. The same people who cry "Systemd does way too much for an init system!" seem to have no problem with all of the shit a display server shouldn't be doing, and they're too fucking retarded to understand that the Wayland protocol will eventually/has already gotten standardized extensions/addons for the sorts of shit they're bitching about (for instance, screensharing is now implemented under Pipewire, which on a side note, will kill another cancer, PA, eventually)

Simply put, and in simple user terms--X is responsible for a lot of the jankiness of the Linux desktop (as you'd expect of a display server that's been kept on life support for 30 years), and when Wayland is eventually adopted, it'll go a LONG way towards bringing Linux to the fucking 21st century.

youtube.com/watch?v=Zsz7Shbnb9c

Good video on the subject.

Phoronix for sure. Ask Michael Larabel.

That's some useless benchmarks because you could make both x.org or wayland win/draw if you make it prioritize latency instead of anything else. And I doubt your benchmark is correct because sway devs already said they never optimized it for that.
Only thing it would do is throw more fuel in this useless debate.

> because you could make both x.org or wayland win/draw if you make it prioritize latency
That's wrong. You can not make a Wayland server prioritizing latency because of the limitations of protocol design.

> Only thing it would do is throw more fuel in this useless debate.
Indeed Wayland is dead on arrival. Almost zero adoption after 10 years development should tell you everything.
Lets stick with X11.

CAN I PLAY MY NATIVE/WINE COMPUTER VIDEO GAMES ON NVIDIA GRAPHICS CARD YET AT EQUAL OR BETTER PERFORMANCE

imagine being a gamer lol haha rofl

So what does Wayland do for me as a user? Other than create churn and bugs and shit I have to fix or change and so on. I don't play video games.

Man, there have been a lot of these threads lately. I'm not the one creating them.
I'm going to need to start tripping to give my posts slightly more credibility. I'm a wlroots developer.

Wayland does not inherently have more latency than composited X. X11's dogshit variable latency (due to a very chatty protocol with a lot of context switches between processes) certainly doesn't help X11's case.

I've been aware of a potential 1 extra frame of latency in wlroots/sway's rendering loop for quite awhile. I intend to fix it eventually, but it's not top of my priority list.

>Almost zero adoption
Gnome on Wayland is the default on Fedora, RHEL, Debian, and probably several others I can't be bothered to look up. I have no way to actually know how many people are using Sway and things like KDE, but from the amount of traffic we get on IRC and even posts I see from people here, there must be quite a few.

Also, Wayland has massively taken off in non-desktop cases (which Wayland was also actually designed for too), where X11's shortcomings would just be a bad joke.

Ugh, I put it in the options field out of habit. Here is that trip.

> Wayland does not inherently have more latency than composited X.
So you are even admitting that X without composition is superior.

> but it's not top of my priority list.
You have the wrong priorities. That's why nobody want's to use this shit.

> Wayland has massively taken off in non-desktop cases
Except for cheap Chinese Phones and TV's there is nothing. Those devices can get away with sub par software.
Desktops heave different performance requirements.

What happened to the #sway-devel channel?

While we're on the subject can someone tell me what GBM stands for?

hi old.reddit.com/user/_Diablo2_

>So you are even admitting that X without composition is superior.
Nice false dichotomy you've got going there.

>You have the wrong priorities. That's why nobody want's to use this shit.
You clearly don't have any idea how open source works. I don't give a fuck what you think; I contributed to wlroots entirely because I wanted to for my own reasons and am not paid for it.
I don't answer to your entitled priorities and simply work on what I feel like.
If YOU have a problem with some software, the best way to fix it is for YOU to do it.

I mainly like/use Wayland because I can watch my dumb chinese cartoons without tearing, which has nothing to do with input latency.

>Desktops heave different performance requirements.
X11's performance is far too terrible to run on low-end hardware. Only desktop-class GPUs (including intel iGPUs) are capable of masking it's god-awful performance and rendering artifacts.

It's still there.

Generic Buffer Manager.

Frame-perfect rendering mainly. Ideally, most users wouldn't even really notice a huge difference.
Developers (including and especially X ones) like it a lot more, so even that alone is enough to slowly move to it over time.

>You clearly don't have any idea how open source works. I don't give a fuck what you think; I contributed to wlroots entirely because I wanted to for my own reasons and am not paid for it.
>I don't answer to your entitled priorities and simply work on what I feel like.
>If YOU have a problem with some software, the best way to fix it is for YOU to do it.
Stop arguing with me and fix fucking wayland you fucking slut bitch pussy software-cunt
Fucking get back to work and fix it then come to me with your gripes
Lazy fuck

>watch my dumb chinese cartoons without tearing
Why can't you do that on X?

Attached: 1558192253241.jpg (600x600, 24K)

How is the Vulkan renderer of wlroots progressing? That'd be the quickest way to shut all the Nvidia cryers up.

Why do you care so much about this? Just use Xorg. There is no need to add this feature to wayland or make some successor to wayand that lets you do it because guess what, there is already a display server that fits your needs: Xorg.

its mental illness check that reddit profile
the times he was posting coincided 1:1 with wayland fud posts

> If YOU have a problem with some software, the best way to fix it is for YOU to do it.
At some point people have to agree on a standard.
Wayland is a bad standard because there is not enough choice.
With X11 you can choose what you want to prioritize. If you want frame perfect rendering without tearing just spin up a compositor. But it comes at a cost.
Wayland made that choice for you.

> X11's performance is far too terrible to run on low-end hardware. Only desktop-class GPUs (including intel iGPUs) are capable of masking it's god-awful performance and rendering artifacts.
You are lying. X11 ran even on my 368. There are X11 distribution that fit on a floppy.

I'm surprised they're not autistically screeching that every graphical program should be run without a display server at all, and they should drive the Linux DRM/KMS interface directly.
That's what you would actually do if you truly wanted to minimise input latency.
That's actually how VR works, because any delay added at all (including anything the X server does) is just too much and leads to people throwing up.

Because X is not capable of delivering that.
Another big part is proper smooth scrolling in Firefox, which tears like a motherfucker. Firefox's wayland support is still experimental, though. It's not quite up to scratch yet, so I still run it through Xwayland.

Slowly.
Vulkan support isn't going to make the proprietary Nvidia driver work. Honestly, it's probably going to make no difference at all for end users.

just checked out pipewire, this shit sounds so fucking cash.

Please sensei, where can i get more modularized services/plugins like this?

>Because X is not capable of delivering that
FUD, I don't even run a compositor and nothing tears (not even firefox scroll).

X11 wasn't designed to give you a choice. It's just fucking old, and that's how they did it back then.
I want to choice of frame-perfect rendering, and X11 doesn't give that choice to me.
Your argument is just stupid and is falling apart.

>You are lying. X11 ran even on my 368. There are X11 distribution that fit on a floppy.
I'm talking about ultra-shitty ARM devices. Think raspberry-pi tier.
It's a very old video, but still entirely relevant: youtube.com/watch?v=Ux-WCpNvRFM
Many types of devices are running hardware of this calibre and can't afford to throw in a $300 GPU.

I've been on the Wayland bandwagon for the past three years. It's honestly hard for me to go back to xorg because of how good Wayland feels.

>they should drive the Linux DRM/KMS interface directly
Why is this bad again?

>Wayland made that choice for you.
You can choose to stay on X11.

>X11 ran even on my 368
I have distinct memories back then of the horrible performance of XFree86 compared to Windows 95. All those context switches have a cost which is especially apparent on old PCs.

>There are X11 distribution that fit on a floppy.
Xorg does not fit on a floppy. BTW, my sway executable is 500KB.

It's extremely hard to do. You can't really expect most applications to do it correctly.
But it's an API that requires and enforces exclusive access. Only 1 program is allowed to control a monitor at a time, so you can't build a traditional multi-window desktop with it. VR gets away with it, because you're not running your traditional desktop on a VR headset (which just appears as a computer monitor).

If you truly did have a specialised application where you truly wanted absolute control over rendering/output, it would be justified.

> I'm talking about ultra-shitty ARM devices.
That's some rare corner case that doesn't even apply any more because drivers have been updated since.

> X11 wasn't designed to give you a choice.
Look.
Your autism wants to put tear free rendering above all else.
My autism wants to put low latency above all else.

Lets design a protocol that satisfies both.

> they should drive the Linux DRM/KMS interface directly
> Why is this bad again?

Good question. As far as I see it I have to design my own windowing protocol.
It will proritize low latency and will by based completely on Vulkan.
Network transparency will be enabled by serializing Vulkan commands with the fosselize library from Valve.

Sway works great but I want my GNOME shell. If Wayland was a display SERVER and not a protocol this problem wouldn't exist. GNOME runs fine on X but it's shit on Wayland where they have to implement everything themselves (because GNOME devs are incompetent).

Also Wayland developers should really look into compositing with the adaptive sync feature turned on (freesync). I'm not exactly sure how it works in DRM/KMS but it should be possible to control when v-sync occurs if you use adaptive sync, therefore skipping all the latency.

>>I mainly like/use Wayland because I can watch my dumb chinese cartoons without tearing
I'm just curious here
are you saying that X tears when playing video?
I've never noticed any tearing with video on X

>Only 1 program is allowed to control a monitor at a time, so you can't build a traditional multi-window desktop with it.
ALSA has a dmix plugin no reason you can't have something like that for video. Anyway for full screen programs Wayland and X should just get out of the way. Even SDL2 has a KMSDRM video driver so you can't say it is hard to develop for.

>rare corner case
How naive you are. Those types of devices are used all over the place.
>Lets design a protocol that satisfies both.
You clearly don't seem to understand how much power a Wayland compositor has over what it does. It does EVERYTHING and holds all of the cards.
Currently, Wayland compositors are currently written to be driven off of vsync to save resources, and does double-buffer rendering with page flips because that's how you avoid rendering artifacts.
But they don't HAVE to be written that way. You could legitimately write a compositor that works completely differently and does single-buffer rendering when it receives a wl_surface.commit and pays absolutely no attention to vsync.
Current developers are not interested in doing this; it's up to people like YOU to write it, instead of just whining about it.

>based completely on Vulkan
Rendering APIs are irrelevant. That's not how low-level Linux graphics works.
The "primitive" type is a dma-buf, which is a handle to some GPU memory. Both OpenGL, Vulkan, and other things such as VA-API are capable of producing them, and the compositor doesn't need to care where they come from.

Wayland compositors are perfectly capable of passing a client buffer straight into the DRM/KMS API and skip the compositing step. It's called direct scan-out. This is an opportunistic optimisation, and doesn't work 100% of the time. This basically does everything you're talking about, but doesn't push the extremely complicated mess that is modesetting onto the clients.

It's definitely been discussed before. A protocol was floating around, but hasn't been accepted upstream yet. Due to the annoying way VRR actually works on some hardware, it's actually got some pretty serious shortcomings. It would only really make sense for fullscreen games.

>Vulkan support isn't going to make the proprietary Nvidia driver work.
Why is that so? According to this
github.com/KhronosGroup/Vulkan-Docs/issues/294
EGL extensions to Vulkan are not needed, and
>In other words, if someone were so inclined, they could write a complete vendor-agnostic wayland compositor and wayland vulkan WSI client on top of nothing but Vulkan 1.1 APIs.
Sounds like it might be possible.

>Wayland compositors are perfectly capable of passing a client buffer straight into the DRM/KMS API and skip the compositing step
Do you know of any compositors that let you do that?

I know my display has annoying flickering/changes in brightness as the FPS fluctuates but the goal here wouldn't even be to run at a lower FPS but rather to reduce latency. The compositor would still run at 60 or 120 or 144 or whatever hz the display supports at a maximum but it would drive the display rather than the display driving it. Again I don't know how VRR actually is implemented but it sounds logical to me. As a bonus you could switch the refresh rate when there's nothing going on like a fullscreen video or game.
I've been experimenting with it but I have no idea how any of the DRM/KMS/GBM/Wayland APIs work lol.

We would still require GBM. Vulkan alone is not enough to perform the types of allocations we need for the DRM/KMS API.
I'm definitely not interested in any type of API that wraps the DRM/KMS API such as VK_KHR_display or EGL_EXT_output_drm. We need proper control over it, and I don't believe that is the correct place for such an API anyway. Not to mention that Mesa doesn't implement those.

With my new design for the renderer/backend of wlroots, it's actually even less likely that there is going to be Nvidia support. The EGLStream model just completely doesn't work. and I'm going all-in with dma-bufs.

>I know my display has annoying flickering/changes in brightness as the FPS fluctuates
Yeah, that's basically it. While VRR allows you to change the refresh rate, you can only do so slowly. Most applications and things like compositors are very erratic with their rendering, which just completely messes with the way that those monitors would work.
I'm not saying that people don't want to add VRR support, it's just not the magic bullet that a lot of people hoped it would've been.

Weston and wlroots at least. I don't know about Gnome and KDE. It's purely opportunistic and the client or user doesn't know about it.
It just takes less resources to do when we can. It's particularly important for low-powered and battery devices.

Still worth looking into, my display is one of the cheapest 144 hz monitors with Freesync anyway. It would be great for video where the FPS doesn't fluctuate but might not match the refresh rate of the display. Think 24 fps on 60 hz or 60 fps on 144 hz.

are you that shemirl or whatever that keeps asking about this around the internet? and linking/bumping bug trackers like a donkey? lel

No idea who that is.

>Weston and wlroots at least.
awesome
>It's purely opportunistic and the client or user doesn't know about it.
Is there a reason for this? If not I might mess with the code to get optional per application support.

fug man just want a stacking sway like waycooler is just a side project, dunno if the guy will have the time to finish it before 2030
kde will take 10 years or more, and gnome is not my type of de to say the least
no need to tell me to code it myself because im a useless weight

>I mainly like/use Wayland because I can watch my dumb chinese cartoons without tearing
based

Yeah, if you implement it. Just like how libinput will support gestures and proper scrolling one day.

>I mainly like/use Wayland because I can watch my dumb chinese cartoons without tearing
bullshit. tearing when dragging windows in xorg is completely unrelated to mpv
xorg tears heavily for me when dragging and resizing windows, but there's no tearing in mpv at all

Because the client doesn't need to know. The application just draws into a buffer, and give it to the compositor.
After that, it's entirely up to the compositor to display (or not display) the buffer however it wants to, whether that's full composition with OpenGL/Vulkan, scanning it out directly with DRM/KMS, a mix of both, or even doing anything else it wants to; the compositor is under no restrictions to do anything.

The requirements for what can be scanned out is somewhat complicated and highly hardware specific as well. But there is a proposal to add hints to the dma-buf protocol to make it more likely that it'll work.

It's highly dependent on your hardware/driver as to how much it tears, if at all. I have definitely had problems with it in the past. Intel iGPUs actually manage to do video decoding quite well, but I used to have an HD 6950 on the radeon driver which really didn't work well.
>dragging and resizing windows
Yeah, resizing is by far X's worst case.

I found I had tearing in Debian (9.9, with X) with VLC and MPV but no tearing in OpenBSD (with their modded version of X they call "xenocara"), not sure why.

>You could legitimately write a compositor that works completely differently and does single-buffer rendering when it receives a
>wl_surface.commit
>and pays absolutely no attention to vsync
I bet over 9000 dollars someone will do it. It's impossible for a non-gamer to appreciate the difference 10ms of lag makes.

Apparently it's impossible for a gamer to appreciate the difference that no tearing makes.

i wonder if this push for game compatibility is worth it, when you get this influx of idiots in return
maybe add some latency to sway until they all leave

>gamers
>knowning how to program

as long as it's not game tearing, it's irrelevant
who cares about tearing when dragging and resizing windows

Without vsync, the game will tear.
When your compositor has fullscreen effects like Mutter or KWin, the tearing becomes very noticeable.

No, you use different things for different purposes. I hate lag in games and tearing in movies equally.

As far as I see it Wayland devs insist on giving no application access to display memory because "Muh tearing".
This means applications have to thrash wl_surface.commit[\code] like there is no tomorrow in order to achieve low latency and drain the battery in the proccess.
All what could have been achieved with a single memory write.

Wayland is pure garbage on the protocol level. No "compositor" will ever be able to fix that.
Abandon ship!

Are you even aware how X works at the protocol level? X does not give you "access to display memory".
That's not how shared memory and GPU memory works.

X consists of drawing commands, which DO get written to the screen immediately, irrespective of any synchronization. These drawing commands are laughably primitive, and nothing but the dumbest suckless-tier software uses it.
Rendering almost always happens in an off-screen buffer (a "pixmap"), and gets blitted to the screen later, even when compositing is not involved.

If you do this the "old" way, you draw into a local block of memory, and push the whole thing over the protocol, uncompressed. You'd be lucky to get 15 FPS with shit like that; even less over the network/
Then we get to hardware acceleration with GLX (which happens server-side), which again goes over the X protocol, but that ran into similar issues. It's just too fucking slow, and frame rates would tank.

Naturally, this shit doesn't happen these days.
If you're doing CPU-accessible buffers, you do it using the MIT-SHM extension, which isn't network capable, and then gets blitted.
If you're doing GPU buffers, you do it using DRI {1,2,3} (happens client-side), which again is not network capable, and then gets blitted.

Wayland was designed with the modern and much more efficient way in mind, and forgoes the ancient shit, and only has the equivalent of MIT-SHM and DRI 2/3.
So Wayland and Modern X are much closer than you think they are; they share a lot of the underlying mechanisms. Wayland just allows for atomic updates and gets rid of all of the legacy shit that nobody uses anymore.

>NEW BAD
>OLD GOOD

Wayland has less latency than X.

X always introduces a random amount of latency to everything because it has a moronic design.

make fast for bideo games pls

Attached: 1553253385423.png (778x512, 45K)

>X11
>low latency
Wayland has less latency than X.

>frogposter
Eww, no. Go back to your containment website.

Attached: 1547446492821.jpg (764x512, 200K)

Recently I tried the Wayland session in KDE and even though it was more buggy than the X one, it was really smooth and some Proton games ran really fucking well too, no tearing or stuttering at all.(unlike on X where everything stutters)
Hopefully it'll mature soon, and maybe Linux distros will really become a viable alternative to Windows.

Nobody said that X11 is great. But at least it lets access the frame buffer directly.
Who cares if this an afterthought or not. This alone makes it superior.
Not letting apps write directly to the frame buffer is a huge mistake ans will be the source for performance problems for years to come.

My mask-based display server will rule the world.... probably.

>But at least it lets access the frame buffer directly
Did you even read what I said? In the first line, I said that it doesn't.
You don't know what you're talking about.
>Not letting apps write directly to the frame buffer is a huge mistake ans will be the source for performance problems for years to come.
It's been working fine for the last 10 or 15 years.

Attached: 1369446960901.png (256x310, 20K)

Wayland is slower than X11 and has worse compatibility.

Systemd was faster than sysv and had perfect compatibility.

We can plainly see why Wayland won't be adopted.

There is absolutely no reason a native Wayland application on Wayland would run any slower than a native X11 application on X11.
Xwayland does have a slight inherent performance penalty (because it's literally Wayland + X), but from what I've seen, it's a few percent at most.

Is there really no alternative to X that isn't Red Hat-shilled garbage?

>native wayland application
There aren't any you would even want to run on X.
So your point is fucking moot.

did you hear about xfway?
its a replacement for xfwm based on sways wlroots

it will be ready in 15 years in time for xfeces 4.15

xfway was actually using libweston, not wlroots.
It indented to add support for some wlroots protocols, though.

Outstanding outstanding outstanding outstanding
outstanding outstanding outstanding outstanding

There are no compton-like effects for the lightweight compositors like sway. I suppose they should be implemented by the devolopers, which is time consuming and unnecessary for some people. Is there am option to create something like Compton, but for Wayland?

It's one mentall ill sway developer. Those idiots just want to swallow the freedesktop cock. And when presented with arguments about why wayland is a failure, they stutter "m-muh security".

> There is absolutely no reason a native Wayland application on Wayland would run any slower than a native X11 application on X11.
This is a lie. Programs that don't use double buffering will be faster on X.
Also xterm will always be faster because it uses drawing primitives provided by the server. The glyphs are cached on the server and just one command puts them instantly on the screen.

Getting rid of drawing primitives is the next big mistake made by idiot Wayland devs.
Give me something like cairo and boom, you have serilization, network transparency and you need one less buffer, which means more performance and less latency. For games you could use Vulkan.

The only drawing primitive Wayland knows is Blit!
What a pathetic pile of useless garbage!

I really want to use Wayland as it was remarkably smooth and lacking in Xorg's latency issues during my brief testing period, but there's just so many programs that run like a complete slog whenever I use it, and unless you're using GNOME it seems to have half assed implementation insofar as DE's are concerned. KDE's Wayland cannot even be said to be in a beta state.

Maybe in 5 or 10 years?

See You clearly have no idea what the Linux graphics landscape looks like and how it actually works.

try wayfire
wayfire.org/

The removal of a drawing API is by design. The only programs that use them are ancient shit like Xterm. The glyph cache was moved into freetype. There is no reason to render fonts in the server anymore. It's also totally useless to do that over the network because you commonly will run into situations where a client asks the server to use a font it doesn't have, and the server has to use a fallback font, resulting in incorrect rendering.
If you want to add network transparency to cairo then try it out, make a wayland protocol that serializes cairo functions and sends them across the wire, I doubt it will have the performance gain you think it will.
If you care that much about latency, just use a TTY.

Just because Gtk and Qt is too stupid to use X11 properly doesn't mean drawing primitives are bad.
Wayland is nothing more than an overcomplicated blitter.
Even the good ol Amiga was better than that because Apps were at least aware of the scanline position.

Getting rid of drawing primitives is a mistake that shows that Wayland devs have zero vision and understanding of the real world outside their Gome echo chamber bubble.

>my methodology is flawled tho
yea because you're comparing a DE to a WM, you tard.
if you at least tried to to a good comparison you wouldve used i3

typing stuff into xterm and filming with at 240fps i got 68ms avg input lag on X (i3) and 138ms on sway (~50% slower).
Moving windows around it’s not that bad but every once in a while there’s a huge stutter on sway, which might be why it feels so sluggish.
I’d try with a wayland-native terminal emulator but couldn’t find any that didn’t require a modern graphics card or a shitload of dependencies.

also libinput is utter trash

Attached: winmove_wayland.webm (1280x720, 1.08M)

Attached: winmove_x.webm (1280x720, 1.43M)

also worth noting, mem usage:

Xwayland 61M + sway 43M + swaybg 16M + swaybar 12M, total 132M (71M w/o Xwayland)

Xorg 30M + i3 14M + i3bar 11M, total 55M

> I’d try with a wayland-native terminal emulator
Alacritty should be quiet dependency free.

I'd switch to Wayland but plank doesn't support it

I’ve tried alacritty and kitty and both complained about my drivers not supporting opengl 3.3

no, wine and nvidia dont support way(intothefuture)land yet

>terminal emulator
>opengl
Where/how did everything go so wrong?

Is wlterm still an thing?
Terminology is also pretty dope but depends on EFL.

>muh sysvinit
>muh minimalism

>even X developers are invested in Wayland
>but it's only one guy! I swear!