On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
You mentioned X11 to me before, when we talked about this idea
over email.
Ah yes. I think X's biggest problem though is that it doesn't do
*enough*. The protocol is fairly efficient for what it does, but
it just doesn't do enough so the commands aren't particularly
compact when you start to get fancier.
For instance, in my crappygui.d, I used XDrawString to draw text.
This was the result: http://arsdnet.net/gui.png
That's a true type font (Bitstream Vera Sans, a fairly good
looking font), but X doesn't support antialiasing.
There's a library called Xft that draws fonts prettier. But how
does it work? Instead of sending DrawText(x, y, "hello world!")
to the display server, it uses a drawing library to render the
text as an image in the application, then sends that image to the
display server.
And BTW if the display doesn't support the alpha blending
extension (the XRender extension), it first takes a partial
screenshot, does the blending in library, and sends that image
back!
Note that the X protocol does not compress the image data. So if
you send a 100x30 pixel image of text, you're shooting some 10 KB
- or double that without XRender - down the network wire instead
of the .... idk exactly for sure, but I think it is about 32
bytes to just send the draw instruction.
Now, you can compress an X stream over ssh, so it isn't always
this bad in practice, but still, since the X display server
doesn't support the expected modern feature, it blows up in
bandwidth to compensate and that can kill the user experience.
Note btw though, you *can* save the image on the display server
to reuse it later, so every time you print a string it doesn't
necessarily send that data across, but I'm not sure if the higher
level libraries actually do this... the downsides of abstractions
is you can miss important details like this.
This is why my simpledisplay.d now has a class Sprite in addition
to class Image, and why Qt has QImages and QPixmaps, but how
often do you think of drawing text as being something that needs
a Pixmap to be efficient? Again the library might handle it, I'm
not sure, but the relatively pathetic performance of a lot of
apps on a remote X connection makes me think they probably don't.
Anyway, the other thing too is all events go to the client
application from the display server, and then the application's
changes go back to the display server. Since X itself doesn't
offer any kind of widgets, a text control for instance would work
like this:
application -> display: draw the box
display -> application: key press event
application -> display: draw the character, advance the cursor,,,
and if oyu have to scroll btw it might draw a whole lot of stuff
(though if you know you're on a potentially networked app, you'd
do something like XCopyArea and tell the display to move a whole
block of data up without resending it all, but again the leaky
abstraction can kill you)
But yeah, the event needs a round trip to react. On a LAN, you're
probably ok, but what about on the open internet where there's
some latency? Well, sometimes it is actually quite fine there
too, I spend a *lot* of time using both X and ssh remotely, but
sometimes it gets to be really, really annoying.
So I'd want to do higher level events too, and the application
can request them. For instance, if all you want is a basic text
input, output something like <textarea></textarea> and let the
display do the details.
(Another really nice benefit here, if we do it right, is it could
use native controls on systems like Windows, or even pipe it to
an external app on unix, and get a nice customized, adaptable
system. Though while it sounds simpler in ways, this is easier
said than done.)
With these higher level events and widgets, unless you need to
override some event, it can just be handled without the round
trip and improve response time on slow connections.
Though, if you do need real time event processing, you're back to
the round trip, but meh, some speedup is better than none.
But, indeed, we don't want to go *too* far either, especially
since then we'd end up with a web browser situation where people
write their applications in the scripting language...
What basic widgets do you have in mind, to keep on the
client-side? Also, just widgets in the client or some basic
layout too?
Layout would be nice too. Ideally, I'd love if my apps worked on
both guis and text mode uis and laying them out would be a bit
different.
For my crappygui.d, I'm aiming to do:
menus, labels, radio box, checkbox, buttons, grid layouts, text
input, slider, number chooser, list boxes, and basic 2d drawing.
Pretty much the basic stuff you get on html forms. Maybe more
later, but I want to actually be able to get this working over
the next weekend or two, so I'm keeping it simple. (And right now
I'm not actually doing network transparency, I'll come back to
that, my basic idea there is to simply forward all the function
calls with rpc.)
As for detaching and reattaching, that is easier to do, the
more state is kept on the server. :)
Yeah, my old DWS idea was to do three applications, but that was
a pain, a lot of duplication to add a new function. So now I want
the middle man program to be really simple, basically a
switchboard, and then the detach/attach messages will be handled
by the application, just shooting its current state to the new
display.
it's more complicated to code all that reattaching
functionality and isn't necessary for most apps, most app devs
don't bother.
If we do it right, it will be zero effort :) GNU Screen has
pretty much pulled it off for unix terminal programs. GUIs have
Remote Desktop and friends... rdp is amazing btw, Microsoft (or
whoever wrote it originally and sold it to them) did an excellent
job and is a decent counter argument to me - I think remote
desktop is a simple viewer, the rdesktop app on unix isn't a
particularly large piece of code and works quite well, but still
I like my way.
