VNC Server

[zpincus]

Woah, strobe, I was just asking a question to see if my thinking was anywhere near correct. While your seemingly angry, cryptic answers have convinced me that you think I\'m a total idiot, they haven\'t convinced me at all why an OS X VNC server is impossible, or even the reasons why you find my thoughts so laughable.

I agree that PDF forwarding will be a great thing. But I think that a VNC Server would still have a useful role, and would be technically fesable.

As far as technical fesability, Strobe\'s belittlement didn\'t really respond to the question I asked.
VNC is framebuffer relay thing that takes rendered pixels and throws them over a network. Now, despite the fact that Quartz is \"third-generation\" and \"speaks PDF,\" no monitor I know of can display anything but pixels. In fact, the whole point of Quartz is to render PDF into pixels that (via a framebuffer-ish thing) are relayed to the monitor. So why can\'t an OS X VNC server tap into this pixel stream? Perhaps one could, but just hasn\'t been written yet? Or perhaps Apple has provided no developer hooks to allow a program to read Quartz\'s framebuffer (or whatever equivalent structure it uses)?
I assume that, despite Strobe\'s assertion that it would be a waste of time, it would not be a huge programming ordeal to provide hooks into this (already present) data structure so that a program (like VNC) could read the pixel stream that Quartz is designed to spit out.
Of course, I still might be totally wrong. Please, someone tell me why or why not this will or won\'t work. Don\'t just tell me to \"confirm it for myself,\" or \"test my theory\" again, Strobe, because I have absolutely no idea how I might go about that, or what the \"it\" you referred to even means.

Zach

[zpincus]

And now a note as to why a VNC Server for OS X would be a good thing, even if we get OS X native forwarding.

1) VNC is a very thin-client protocol. That is, a client is small, relatively easy to write, does very little, and requires very little from the processor or RAM. This leads to huge multiplatform capabilities. I\'ve seen palmtop devices running X windows remotely over VNC. I seriously doubt that such a device could handle an Exceed or xTools type solution, even if there was a developer intrepid enough to try to make one.

The genius of VNC is that it does not send commands native to any particular environment across the network. Instead, the VNC server pre-renders the screen (*NIX) or copies the pre-rendered screen (Mac, Win) and sends pixels over a network, thus assuming absolutely NOTHING about the nature of the client. (This is also the root of the speed problem, because pushing pixels is slow. But, it is really easy on the client, which X11-stype forwarding is emphatically not, which is why xTools and Exceed cost a lot of money.)

I have yet to be convinced that the fact that Quartz uses PDF commands means that remote clients will be able to be anywhere near as thin as even ghostview. Rendering static PDF files is emphatically not the same as being able to render streaming PDF commands in real time, if indeed this is what OS X forwarding will be. (Strobes last post makes me think that this will indeed be the case. Comparisons to NeXT are very instructive -- thanks!)

I tend to think that insofar as the Quartz layer itself is far more complicated than ghostview, any remote client recieving windowing commands intended for Quartz to render will need significantly more than the ghostview codebase can offer.
If OS X forwarding follows the X11 model, the remote server will need the full capabilities of a local display server in order to properly render the screen. And as nice as Ghostivew and other PDF viewers are, they are not Quartz, and I really dont think that making them quote Quartz compatible would be a trivial thing. Just cranking up the render speed so such a thing would be real-time usable could prove very difficult.
In fact, if there is or will be an API for a VNC server to tap into the Quartz-generated pixel stream (see previous post) I would bet that porting a VNC server to OS X would be far, far easier than hacking up Ghostview or something to be a full-fledged OS X client on even one platform!

Of course, I might be wrong. Did anyone ever make any postscript interpreters into remote clients for NeXT? If this was easily done, than I must concede this point to Strobe.

2) VNC is here already. There is a large base of tested, running clients on every OS imaginable . More OSs have VNC ports than have Ghostview ports. Even if a remote client of X can be as thin as VNC and can build off of Ghostview, it will take a long time for the ports to reach the penetrance that VNC has (if ever).
[Strobe, when I said Quartz clients of onther systems would be \"slow in coming\" I meant porting speed, not render or network speed. Which, you are right, PDF forwarding would beat VNC in any day.]

Sorry for the long post. My point here is that I think that both X11 or NeXT-style forwarding and VNC are complimentary solutions, each useful in areas where the other is not. (X11 for speed, VNC for ease of client porting and for running clients on nontraditional platforms -- like the Java VNC client that allows me to operate my system from within a web page.)

Zach

[Casey]

I'm half expecting Apple to release remote GUI login in some form at some time in the future... but VNC, for reasons mentioned above, would be nice too.

The man page for the Open command (which treats files as if you opened them in the GUI) list this option:

-NXHost opens the file on the specified host (if its win-
dow server is public).

I've tried sending my Opens to a remote xserver... no go. the stuff just opens locally.

(I'm actually more interested in command line access to Applescript and the OSA libraries in all these GUI apps... but thats another thread)

-casey

[strobe]

The display is comprised of pixels, but so is a photoshop composite. The bottom line is VNC is designed to work with a picture where you have groups of similar pixels being moved around. This is not what happens in Quartz.

It's not practical.

You can test it for youself by playing a flash movie with semitransparent objects in Win32 and viewing it remotely. It's a very easy thing to test.

As for ghostview you don't need to implement all of PDF for it to be useful. I used X11 servers which didn't implement every X11 command and font but it worked.

Quartz uses PDF 1.3 which is an open standard. There are several PDF 1.3 renderers like OmniPDF.

For all the remote administration I do I use the command line. The only things I can't do on the command line don't have anything to do with remote administration anyway. The rest of the applications are mostly graphical.

A better solution may be to use an advanced movie codec like Q2 or H239.

[zpincus]

Strobe, I've been waiting since you posted this:

VNC isn't designed for what's termed '3rd generation display servers'. In X11 or Win32 each pixel is drawn by one process directly to screen. Quartz doesn't work that way. Try dragging a semi-transparent object in Win32 over VNC and watch it slow to a crawl.

several weeks ago, for you to explain how the fact that semitransparent objects bog down win32 VNC applies to OS X. (Which as you yourself mentioned, uses an entirely different window server paradigm than Win32.)
You just keep repeating the same thing in every post since with absolutely no explanation of what the results of this "test" might show or prove, or what any of this implies for Quartz, or how you can even begin to show that the problem isn't just a bug in the Win32 server. Your "test" is certainly not conclusive, and I really don't see what it shows about anything, save perhaps that transparent graphics make VNC slow. This is not news, and it certainly doesn't show how there would be a Quartz-specific failure of VNC (quite the opposite in fact!)
For that matter, Aqua really doesn't use enough transparency that the fact that the VNC encoding schemes don't work so hot for moving transparent elements would make it unusably slow. Looking at my screen right now,perhaps 1/64th is transparent objects (window shadows), and unless you spend all day moving windows around, most of the time these elements don't move, which is what you claim chokes VNC.
(And note that OS 9 generates transparent icons as you drag them, but this hardly affects VNC at all.)
And if a transparent element doesn't move at all, it is totally invisible to VNC except for the first time it is sent.

I see how this might make things like menus in OS X a bit slower, however, because VNC can't compress a translucent menu into a huge block of white and then text, but instead would have to send the whole menu as a less-well compressed image. But this certainly doesn't destroy the utility of VNC. When you foreground a window with graphics in it, you make VNC do the exact same thing!
And good god, on my ethernet connection I can turn off ALL the encodings except raw and still get good performance out of VNC. That is, just sending the changed pixels without any sort of encoding at all works fine for me. Your point

The bottom line is VNC is designed to work with a picture where you have groups of similar pixels being moved around.

is entirely fallacious. Certain VNC encodings work best for these scenarios, true, but VNC is by no means crippled in their absence.

As for "compositing" issue (disregarding the transparency), your point strikes me as entirely inane. Quartz would do the compositing long before VNC ever had to deal with the bit stream. So please tell me how the origin of the pixels makes a lick of difference to the VNC server!

So please explain exactly what you mean in terms of the VNC architecture and encoding schemes, without recourse to inconclusive tests on an admittedly different platform and port of the software. In short, convince me that you understand the VNC architecture at all and we'll go from there.

Zach

[strobe]

The origin matters because the pixels do not remain the same when moved, in fact the pixels ARE NOT MOVED. The layers are moved thus changing the pixels.

Full screen sorenson movie streaming might be a better solution. It accounts for images which move and change. There are other codecs which require more CPU like H.329.

VNC is just another codec. Perhaps one solution is to make VNC more modular so the video images can use other codecs.

A flash movie was merely an example of how a Quartz display would change when moving stuff. VNC is slow even when highlighting the title bar in twm! How on earth is it going to handle Quartz I ask you..the codec is impractical!