Dual X Servers Running Side-By-Side With Wayland

[phoronix]

Phoronix: Dual X Servers Running Side-By-Side With Wayland

It was just earlier this week that Wayland picked up a terminal as Kristian Høgsberg was working to get a real X Server running under this mini display server with integrated compositing manager that's designed around technologies like kernel mode-setting and the Graphics Execution Manager. Now though Wayland has reached another milestone...

http://www.phoronix.com/vr.php?view=NjkyMg

[Louise]

I wonder how the X.org developers feel about this.

I would assume, that would prefer X over anything else...

[ethana2]

The future is bright :)

[Vadi]

The future is bright :)

Not really. Isn't this 1 guy working on his spare time?

[oblivious_maximus]

Not really. Isn't this 1 guy working on his spare time?Funny, that sounds a lot like how an apparently quite popular project I recently heard about started - I think they call it a kernel or something.

[Thetargos]

Funny, that sounds a lot like how an apparently quite popular project I recently heard about started - I think they call it a kernel or something.

Love the pun! :D

[StringCheesian]

But isn't this designed for embedded devices, not desktop environments?

[Regenwald]

it grows and grows...seems to be able to replace xserver sometime...

[quintesse]

it grows and grows...seems to be able to replace xserver sometime...

Replace?? They got TWO of them running on top of it!

But I do wonder which low level parts of X it could be replacing? And I assume one of the advantages here is simplicity? That Wayland is able to do some things quite easily (like compositing) and therefore takes that burden away from the X server?

[Regenwald]

it's unbelievable how fast they develop it. afaik, it's just one guy or at least a bunch of guys, not many people. x.org took several months to get features that these guys add by several weeks.
ps: i've the feeling that it got better than expected?! perhaps not just as an alternative for embedded systems? i'm hoping..

[bridgman]

I'm just guessing, but I don't think krh wrote an X server replacement here; this would probably be X in its current form with drivers that use Wayland for drawing rather than hitting hardware directly.

[super7]

I'm no expert, but I would guess he can make a lot of progress since there is nothing stopping him from using existing Xserver and X.org code. It's not like he's starting completely from scratch...we all have the privilege to watch open source's benefits in action. I hope he continues making progress.

[airlied]

I'm just guessing, but I don't think krh wrote an X server replacement here; this would probably be X in its current form with drivers that use Wayland for drawing rather than hitting hardware directly.

oh it uses the hw alright, it just redirectks kms front buffers to wayland.

all this stuff needs kms.

Dave

[hoegsberg]

I have a FAQ page over in the Google group for the project that answers many of the questions here:

http://groups.google.com/group/wayland-display-server/web/frequently-askeds-questions

cheers,
Kristian

[Vadi]

Thanks for the faq

[NeoBrain]

Hey, just wondering wether running two x servers under wayland could finally solve the "no minimizing in Linux" problem: Imagine the primary X server running under Wayland. The user starts some game, which gets hosted on a second x server, but wayland just draws the content of the second x server's front buffer. Now, if the user presses some key-kombo, Wayland renders only the first front buffer. Of course, there still needed to be done some hacking on mode setting (i.e. when the game starts), but technically this sounds feasible, doesn't it?

[drag]

Here let me explain something to you about XServers.

There are already lots and lots of X Servers.

A few off the top of my head are:

Xnest -- runs a embedded X server on your desktop.
Xephyr -- Replacement for Xnest that includes acceleration features.
Kdrive -- small X server
Darwin -- X for OS X
DMX -- distributed multihead X (with Chromium you can get distributed OpenGL acceleration, btw)
Xfree -- the default X server from X.org

So X.org provides the 'X Window System'. 'X Windows' as you probably know is a network protocol. Like HTTP.

So your X Server is equivalent to your Web Browser.
Then X Clients are equivalent to Web Servers.
X Clients talk to X servers using X Windows. Web Servers talk to Web Browsers using HTTP.

Now the only confusing part is that the 'X Server' part of X Windows is almost always on your local computer. So it's a bit opposite from the terms we normally use. This gives you a idea about how old X Windows is.

Anyways...

So the 'X Window System' is divided up into two parts:
DDX -- Device Dependent X
and then
DIX -- Device Independent X.

The X Server is the DDX stuff. X.org provides many different sorts of DDX's.

DIX is all the libraries and stuff that X.org provides that is used by various applications and toolkits to build X clients.


Soo....

If you think that Wayland is some sort of upstart or challenger to X.org then think again. That's just not how this works. Wayland is still going to have huge dependencies on X.org-provided stuff in order to work.

Anyways...

from his own blog:
http://hoegsberg.blogspot.com/2008/11/premature-publicity-is-better-than-no.html

The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.


Sooo... It's not really a X Server at all and is not intended to be a replacement.

Instead if your going to be using it to run X Windows application you will have a X Windows server running, but with all the pixmaps rendered off-screen.. Then Wayland takes those pixmaps and sucks it down using it's own composted manager.

So it's a new sort of display manager that can use pixmaps displayed from a existing X Server.

Or something like that. Don't really understand all of it.

------------------------

Maybe the goal is to get a X Server running as a sort of daemon or something were you can then separate the X stuff from the Display stuff. Then you can possibly have detachable sessions (like using bash + screen) or have you application survive a driver crash or allow people to turn off the display directly and redirect it to other hardware or systems.

Or something like that. Like I said I don't really understand the point exactly.

[elanthis]

Drag: Wayland does replace the X server at one level of the stack. It can in time completely replace the X server: you don't have to run an X server at all with Wayland, unless you want to run existing X clients.

Assuming Wayland actually gets to a usable and complete point, and the design is proven solid, then developers can start porting apps (or toolkits, really) to Wayland's native protocol. Assuming all of your apps are ported, there'd be no need for you to have an X server running at all. You could fire up an X server on-demand for apps that need it, such as old closed binaries or old unported apps. That scenario is probably a good number of years away, though.

If you read the FAQ Kristian posted, that's all spelled out for you. It's pretty clear and informative. :)

The only thing I don't see answered (plz to answer Kristian kthxbai) is whether or not Wayland's protocol intends to support remote connections; if not, X would remain useful indefinitely for remote client support, but not for local clients.

The point of Wayland is essentially that 90% of what X does isn't necessary any more: all of the hardware setup is done in the kernel, all of the rendering is done in the clients, and all of the input events are handled by unified driver interfaces. Nested windows are considered harmful these days, the mandatory core X drawing protocol is essentially unused, and even RENDER is being replaced by clients doing rendering straight to pixmap buffers using GL. The only thing X is really needed for (aside from network support) is the functionality that Wayland provides, but Wayland does it without all the legacy protocol requirements. In the short term, Wayland is only useful as an X session multiplexer. Long term, it has the potential to make X unnecessary for most setups.

It's a really neat total redesign of the graphics stack in face of KMS/GEM/DRI2/EGL, and because X can so easily be run as a nested client, it can be done in a very transition-friendly manner so there's no "port or die" mandate like so many other software replacements force on developers. Pretty cool. :)

[hoegsberg]

Drag: Wayland does replace the X server at one level of the stack. It can in time completely replace the X server: you don't have to run an X server at all with Wayland, unless you want to run existing X clients.

Assuming Wayland actually gets to a usable and complete point, and the design is proven solid, then developers can start porting apps (or toolkits, really) to Wayland's native protocol. Assuming all of your apps are ported, there'd be no need for you to have an X server running at all. You could fire up an X server on-demand for apps that need it, such as old closed binaries or old unported apps. That scenario is probably a good number of years away, though.

If you read the FAQ Kristian posted, that's all spelled out for you. It's pretty clear and informative. :)

The only thing I don't see answered (plz to answer Kristian kthxbai) is whether or not Wayland's protocol intends to support remote connections; if not, X would remain useful indefinitely for remote client support, but not for local clients.

The point of Wayland is essentially that 90% of what X does isn't necessary any more: all of the hardware setup is done in the kernel, all of the rendering is done in the clients, and all of the input events are handled by unified driver interfaces. Nested windows are considered harmful these days, the mandatory core X drawing protocol is essentially unused, and even RENDER is being replaced by clients doing rendering straight to pixmap buffers using GL. The only thing X is really needed for (aside from network support) is the functionality that Wayland provides, but Wayland does it without all the legacy protocol requirements. In the short term, Wayland is only useful as an X session multiplexer. Long term, it has the potential to make X unnecessary for most setups.

It's a really neat total redesign of the graphics stack in face of KMS/GEM/DRI2/EGL, and because X can so easily be run as a nested client, it can be done in a very transition-friendly manner so there's no "port or die" mandate like so many other software replacements force on developers. Pretty cool. :)

That's a pretty good writeup of the major points in Wayland. As for the question about remote client support: no, I consider that outside the scope of Wayland. If you want remote rendering, Wayland is a good environment for running your remote display server such as X.org or an RDP server or similar, either full-screen or in a root-less fashion. Or somebody can invent their own remote display protocol on top of Wayland.

I've been thinking that maybe it's possible to implement a "remote compositor" that forwards the Wayland requets over the network to a remote display, but I haven't spent much time on that idea :)

[some-guy]

Would it be something like the compiz/dmx NOMAD patches?

[quintesse]

Now the only confusing part is that the 'X Server' part of X Windows is almost always on your local computer. So it's a bit opposite from the terms we normally use. This gives you a idea about how old X Windows is.

The age of the X Windows system has nothing to do with it because the terminology makes perfect sense. On your local system exists a process that is able to draw windows, lines, icons, text and all that stuff. And it allows others to connect to it and ask it to draw things on the screen.

Normally anything that provides a service by allowing others to connect to it is called a "server" and the ones doing the connecting are called "clients".

You may associate a "server" as something remote and far away and a "client" as something that runs on your local system but in many cases that is just wrong.

Just see your screen as the "server" and the applications you start as the "clients" "asking the server" to paint their windows.

[elanthis]

If you want remote rendering, Wayland is a good environment for running your remote display server such as X.org or an RDP server or similar, either full-screen or in a root-less fashion. Or somebody can invent their own remote display protocol on top of Wayland.

Well, RDP sucks nuts for over-the-Net connections or for remote real-time rendering jobs. I wouldn't mind either just keeping X or having some new protocol so long as one binary can run both locally and remotely without modification. That is one very clear advantage of the X setup -- your apps just work in both configurations and even get full GL acceleration over the network thanks to GLX.

Granted, these days, the only reason I personally use remote X at all is for running a handful of sysconfig tools that the developers decided to make GUI-only. :/ (And for making Windows-using friends jealous when I run Quake on my quad-core desktop at home while displaying/playing it on my laptop at their house. :)

Thin-client setups though really need a solid, bandwidth-efficient, extensible, low-overhead, fully-accelerated, low-latency, no-setup rendering protocol. Given the apparent future adoption of GL at all levels of the rendering stack, maybe all we need is just a compressed X-less GLX plus a basic input/event mechanism.

[elanthis]

Actually, a few more questions for you Kristian. First, how do you think things like drag-n-drop and menus should be handled? X right now uses mouse/keyboard grabs, which I despise with all my being. That approach means that when an app has a grab and deadlocks (like Evolution seems to do one out of 20 times for me when trying to drag-n-drop messages between folders), the whole damn X session becomes completely and utterly unusable until I switch to a VT and SIGKILL the app. Will it possible in Wayland to implement those features, as well as things like windowed-games that want to track mouse position even when it's outside the window, without grabs?

If not, would it at least be feasible to detect deadlocks (similar to the usual "this app is not responding" detection certain WMs have) and break the grab, and/or allow something like ctrl-alt-del or ctrl-alt-bksp to break it? Ideally there should be a key combination that always displays a non-overridable safe system dialog like Windows has, so you always have a way to take back control of the machine in the face of a badly behaving application, even if it's full-screen and has all input grabbed and is locked up (like a game). That's certainly possible in X with a little work. My second question is whether or not you already have plans for Wayland to support such a facility.

The third question is: do you think Wayland should lock itself in memory (which may require root or partial-root privileges) so it never gets swapped out and thus cause the whole session to lock? Another problem related to dead-locked apps is apps that consume all the RAM and cause everything -- including the WM, X server (including input code), VT login processes, and so on to all be swapped to disk. Even switching to a virtual console to kill the app can end up being impossible, because it takes forever for X to switch VTs, forever to wait for the login process on the VT to be paged in, forever for the bash session to start, and then forever for kill/killall to start. Depending on the specific behavior of the app, the OOM killer might not ever kick in, so there's apparently no way to recover. I've had instances where I could manage to get to a logged-in console but killall couldn't manage to start even 2 hours after I typed in the command. Older versions of Firefox have done this to me on more than one occasion, as have a couple games.

Thanks!

[drag]

Well then I wouldn't consider it a 'replacement' for X so much. That implies replicated functionality. A 'alternative' to X would probably be more accurate.

At least that's how I got about defining terms when I talk to people about replacing Exchange servers or other such things. Like I can say that: "Linux can offer lots of alternatives to using Exchange, but right now it offers no real replacement for it.. but Openchange (not to be confused with openexchange) is in the works so that you can eventually use a Linux server to provide a drop in replacement."

That sort of thing. It's a bit nitpicky, I know.

But I think people would be more interested in it as a completely new graphics system for Linux as opposed to a 'just a new X server'. We already have lots and lots of different X Servers.


-----------------------------------------------



Hell, in light of what you guys were talking about it may be time for a entire new X Windows protocol. Something that's updated.

The network functionality of X is much to valuable to leave it up to 'use vnc' or stuff like that. X is a much better performer nowadays over the network then it used to be. Just look at LTSP. And it would suck to force toolkit makers to support multiple backends to get the benefits of Wayland without sacrificing good thin client support.

For example I'll setup a 1024x768 Xephyr display to run remote Gnome Desktop over encrypted SSH tunnel. This thing is _snappy_. It's a much better performer over (a rather slow, lossy, and overgrown corporate network, from one building to another) 100Mb/s ethernet connect then Rdesktop is able to do over localhost to Windows running on a VM. (with Rdesktop itself performing much better then the VNC-based terminal that I get with Fedora's virt-manager)

I also noticed that with Opengl applications and AIGLX I could play full screen (like 1280x960 or so) Return to Castle Wolfenstien over (my faster home network) 100Mb/s connection, even with ssh encryption. Like 20-40fps. Blender worked and all that. This was a while ago when AIGLX first came out. Over the same connection Gnome and KDE apps had more noticable lag.

If like your saying that X apps are barely using X aymore, or at least using it less and less, then it may be a good time to redesign X protocol to make it easier to compress and avoid the ping-pong type client-server behavior that causes lots of performance issues over higher latency connections.

It could be something that could be dramatically simplified over what is now.

The security of X is one huge thing that is holding it back also. This is something that could be addressed. Especially when you move X completely off the hardware.

Then people could keep the 'legacy xfree'-style server for backwards compatibility with older protocols.


Just a suggestion.

[elanthis]

I also noticed that with Opengl applications and AIGLX I could play full screen (like 1280x960 or so) Return to Castle Wolfenstien over (my faster home network) 100Mb/s connection, even with ssh encryption. Like 20-40fps. Blender worked and all that. This was a while ago when AIGLX first came out. Over the same connection Gnome and KDE apps had more noticable lag.

If like your saying that X apps are barely using X aymore, or at least using it less and less, then it may be a good time to redesign X protocol to make it easier to compress and avoid the ping-pong type client-server behavior that causes lots of performance issues over higher latency connections.


The lag in KDE/GNOME apps can be from a combination of things; usually not the protocol itself. Certain toolkit rendering engines try to hardware accelerate everything they can but then fallback on software rendering for things they can't -- so you end up having to copy buffers back and forth over the network (not to mention hardware buses) multiple times to render things. The roundtrips are also not really the protocol's fault. The xlib library requires a lot of technically unnecessary roundtrips, for which xcb was created to fix (no need for a protocol change). Some themes or widgets also just do relatively dumb things with rendering, such ss trying to grab copies of buffers for things that could be done in a copy-free manner (especially on modern hardware w/ shaders).

In the face of networked apps -- and even to a lesser extent all apps -- it is generally better to either render _everything_ in the hardware or to render everything in software. Otherwise you have to copy buffers back and forth, and that slaughters performance in oh so many ways.

The security of X is one huge thing that is holding it back also. This is something that could be addressed. Especially when you move X completely off the hardware.

How so? If you're talking about requiring root access, that's caused by the driver model. X on Wayland would not require root access, nor would X with an update DDX/kernel interface.

If you mean controlling which apps can talk to other apps with the protocol, I believe that's what XACE is supposed to tackle. I have to yet to evne find a specification for XACE online, though, so I'm unsure...

Then people could keep the 'legacy xfree'-style server for backwards compatibility with older protocols.

"legacy free" and "backwards compatible" are two entirely contradicting terms. :)

[drag]

In the face of networked apps -- and even to a lesser extent all apps -- it is generally better to either render _everything_ in the hardware or to render everything in software. Otherwise you have to copy buffers back and forth, and that slaughters performance in oh so many ways.

Well at least Gnome stuff is much better now then the time period I was talking about then.

I had a discussion once about gnome-terminal vs xterm and performance and people were telling me that xterm would provide better or more consistent performance then gnome-terminal because it was closer to the x protocol or something like that. Less gtk bullshit getting in the way or whatever. I did benchmarks and gnome was obviously using tricks with text rendering for remote X apps and whatnot and gnome-terminal easily trounced xterm. Wasn't even a comparison.

Like I mentioned up there it's my current experience (running Fedora 10 on my laptop) that running a Xephyr-based nested X server with gnome-session (from a CentOS 5.2 system) over AES128-encrypted SSH tunnel over 100Mb/s connection is able to provide a much better 'feel' and responsive interface then Rdesktop running over "localhost" (well not loop-back, but over virtual network) to a Windows VM.

This is a KVM-based Windows VM that was created and managed using Fedora's virt-manager stuff.

In turn I am using Rdesktop becuase it performed much better at bigger sizes then the VNC stuff that is provided by default by virt-manager to handle graphical consoles.

And KVM and the virtual network is no slouch either, mind you.


It may or may not be worth your time to do what I am suggesting. Or it may be something that other people need to do.

But I figure with lessons learned with NX and whatever the GTK/Gnome guys are doing, plus the lack of usefulness for the majority of functionality that X protocol provides then maybe it's just time for a new, much streamlined X protocol.




How so? If you're talking about requiring root access, that's caused by the driver model. X on Wayland would not require root access, nor would X with an update DDX/kernel interface.


I am talking about X as the network protocol. If you run X outside of a ssh tunnel then it can easily get sniffed. It's a chronic issue and if you every tried to run a nested X server without the '-ac' switch to disable the access controls then its very difficult to get working.

If like you guys said that X protocol requires a lot of extra horseshit that nobody uses anymore then it's probably time to update the X protocol. Maybe make it X12 or something.

It's been done in the past, obviously.

"legacy free" and "backwards compatible" are two entirely contradicting terms.

Ya read it wrong. Legacy xfree-style X server. As in X11R6 compatible. Which is what we all use now. :)

'legacy xfree'-style server


X is very crusty and one of the big things is backwards compatibility. So you just shovel that off to the side and modern apps would use the (currently imaginary) X12 protocol that (my imaginary) Wayland-style system would support natively.

[drag]

I donno.

I mean remote X isn't something that is critical for desktops. Never was. So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.

I like X network functionality. I don't give two squats about the actual nature of the protocol itself, though.

But one thing to consider is that from X's original conception in 1983-ish to 1987 there were 11 different versions of the X protocol. We have been using version 11 for 21 years now. One of the big reasons (according to wikipedia) for the change from X10 to X11 was to make it more 'hardware independent'.

Also there is functionality present in competitors... like with Vista your able to have disconnect between the applications and the display. If you log into rdesktop, for example, you can view and interact with whatever application you had left open on your last session.

Also with Vista if your display crashes from buggy drivers (or whatnot) then the display will go to black, Vista will attempt to restart the graphics stuff, and then if it works you can log back into your previous session. For lots of users if their display drivers crap out then all they see is a brief black screen.

So it would be nice to have that same sort of functionality for Linux.

[quintesse]

I mean remote X isn't something that is critical for desktops. Never was.

Uhm, you probably weren't alive yet or too young to remember the time of the dumb and thin terminals? When I started studying things were all done remotely. The idea that some time you would have multiples of that power in your mobile phone was pure science fiction :)

So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.

Things are not fast and wonderful right now? I don't see X apps being outperformed by their Windows counterparts and we're able to do Vista-like stuff with 20+ year old technology? It seems be doing pretty well IMHO.

That doesn't mean I don't think we should take a look at bringing all of this technology into the new millennium, but lets not throw out the baby with the bath water.

[Ex-Cyber]

I mean remote X isn't something that is critical for desktops. Never was. So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.People who have lurked in the Unix/Linux scene long enough to have seen this argument a dozen times will take this statement to mean that you don't support getting rid of remote X (even if that is denying the antecedent ;)).

[drag]

Well I like the remote features of X. I think it's very cool.

There are things that could make it very more cooler.. like the ability to detatch and re-attach clients to other X servers and stuff. You can do that with Sun's X terminals, for example. Also with Windows you can attatch remotely using rdesktop and get access to the apps from your last session. Also with Vista if the display/graphics drivers crash for whatever reason the system resets the graphics and you don't loose your session either.

I mean I use remote X every day. I like that feature, I don't care much about X either way. If the protocol can be updated or replaced to make things simplier then that would be wonderful.

.
Things are not fast and wonderful right now? I don't see X apps being outperformed by their Windows counterparts and we're able to do Vista-like stuff with 20+ year old technology? It seems be doing pretty well IMHO.


Well I didn't mean it like 'fast' as in raw performance, but of maintainability and whatnot. 'Fast' as in the ability to get things done in a timely manner and having good fast performance. (X isn't wonderful right now, though. :) )

There are only so many hackers out there with the capabilities of working with X and graphics. If simplifying things means getting rid of X completely and that means easier times for developers.. then I support it.

--------------------------

The only thing I don't like about Wayland is the "oh we'll support X through composited interface, but toolkits like GTK can be ported to support it natively".

This is the sort of 'multiple backend' thing that plagues Linux sound stuff. Like "Oh, if Alsa doesn't work use OSS" type things.. or Amarok supporting a dozen different audio APIs. It's a mess and each 'choice' brings with it's own advantages and broken functionality. Confusing and difficult and time consuming.

The problem is that in order to get that extra layer of abstraction too support two sorts of backends like X vs Wayland means a lot of extra work. Plus unless you can get functionality effectively the same on both systems then that means that your going to get stuck with the lowest common denominator.. If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one. It'll get stuck in between them and only using functionality that is present in both environment.

So if your going to create a alternative you need to make sure that alternative has the capabilities of replacing X completely. Sure keep a X server around for compatibility with legacy applications and whatnot, but make Wayland nice enough and with the required functionality that people need from a GUI system so all future developments happen on that system.

Something like that.

Needless layers of abstraction really hurt Linux and makes things more difficult. So either work on replacement of X completely (or a updated XR12 protocol) and hope it takes off, or encourage people never to program in Wayland directly except for special purposes and just use it for managing the display. Something, to avoid the division.

[elanthis]

The only thing I don't like about Wayland is the "oh we'll support X through composited interface, but toolkits like GTK can be ported to support it natively".


GTK already supports 5 or 6 backends. It's intended to be portable. Same with any other toolkit. Wayland won't require any extra layers at all. If anything, Wayland essentially removes from the graphics stack the layers that exist within X today.

If -- and that's a big "if" -- Wayland's model is determined to truly be the successor to X, then it's really just a matter of adding a new backend to a toolkit that already has half a dozen.

If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one.

See, though, the entire reason Wayland works the way it does is because real applications don't need additional features in EITHER backend. The future that we're approaching is one in which all rendering is done via OpenGL (usually through a higher-level toolkit/library interface), in which X subwindows are unused, in which DBUS facilitates all high-level desktop app communication, and in which all X really does is provide the basic window stacking/management features on top of the in-kernel or library-ified graphics and input components. That's why Wayland is so simple. Nobody really needs the features the Wayland design lacks. All modern applications need from the windowing system are windows, direct rendering, compositing, input, and a few other basics.

Almost all interesting features -- including allowing apps to move between X servers like you just asked for, as well as networking -- are really toolkit problems and library problems. A modern toolkit's abstraction layer needs very little outside of a way of getting hold of an OpenGL context, getting input events, and low-level stuff like threading and I/O and basic audio. Current toolkits have bigger abstraction layers mostly just because they were designed in the day and age when the X drawing API or Windows' GDI API were actually considered useful.