VNC Server
- Thread starter Casey
- Start date
,
strobe
Puny Member
Not going to happen.
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.
A more practical solution would be a PDF equivalent of xhost.
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.
A more practical solution would be a PDF equivalent of xhost.
While a PDF version of X windows forwarding would be nice, it still leaves a few gaps.
1) ssh won't be likely to be able to natively forward the PDF commands in an encrypted state. Apple will need to design a new tool for this.
2) it won't work cross-platform like VNC does.
Number 2 is why VNC is so huge for me and a lot of people I go to school with. PDF forwarding won't let me use my OS X box from, say, a windows machine, unless someone writes an XTools or eXceed type solution that is likely to be slow in coming and very expensive. (And at least Xtools only happened b/c Xfree86 is opensource -- can you imagine trying to replicate Quartz on x86 with no code to go from?)
I agree with Strobe that a VNC that deals with Quartz isn't going to be an easy port. But I don't think it will be impossible.
At some point, Quartz spits out the final, rendered screen, pixel by pixel, and sends it to the monitor. I don't see why it would be impossible for VNC to intercept this and send it on a network. Just treat Quartz as the only process that draws pixels, and ignore the other processes that interact with Quartz on earlier levels. This would also solve the transparency problem, because then I'd imagine the VNC server wouldn't bog down on transparent dragging any more than Quartz does -- because it is still Quartz's responsibility to render transparency, and not VNCServer's.
Now, this notion is a little strange to those familiar with *NIX VNCServers, where the VNCServer can actually substitute for the window server (ie: you don't need to be actively running X for VNC to work.)
But even in OS 9, VNCServer sits on top of Apple's "windows server." It can't generate an independant display on its own, and instead the VNC server mediates communication with the OS 9 display over the network. (So if you are VNCing into an OS 9 box, your mouse movements on the "VNC side" makes the cursor actually move on the screen.)
So there's a precdent for VNC servers sitting on top of and not replacing a window server... can this be extended to OS X/Quartz? I have no idea.
It might take Apple's cooperation, though, and perhaps a lot of it. And of course, my thinking on this may be totally wrong. Does anyone who has done VNC work before know if this is a totally faulty idea?
Anyway, I'm going right now to nag Apple and tell them to make it easy to do a VNC Server for Quartz, just on the off chance that it is possible.
Zach
1) ssh won't be likely to be able to natively forward the PDF commands in an encrypted state. Apple will need to design a new tool for this.
2) it won't work cross-platform like VNC does.
Number 2 is why VNC is so huge for me and a lot of people I go to school with. PDF forwarding won't let me use my OS X box from, say, a windows machine, unless someone writes an XTools or eXceed type solution that is likely to be slow in coming and very expensive. (And at least Xtools only happened b/c Xfree86 is opensource -- can you imagine trying to replicate Quartz on x86 with no code to go from?)
I agree with Strobe that a VNC that deals with Quartz isn't going to be an easy port. But I don't think it will be impossible.
At some point, Quartz spits out the final, rendered screen, pixel by pixel, and sends it to the monitor. I don't see why it would be impossible for VNC to intercept this and send it on a network. Just treat Quartz as the only process that draws pixels, and ignore the other processes that interact with Quartz on earlier levels. This would also solve the transparency problem, because then I'd imagine the VNC server wouldn't bog down on transparent dragging any more than Quartz does -- because it is still Quartz's responsibility to render transparency, and not VNCServer's.
Now, this notion is a little strange to those familiar with *NIX VNCServers, where the VNCServer can actually substitute for the window server (ie: you don't need to be actively running X for VNC to work.)
But even in OS 9, VNCServer sits on top of Apple's "windows server." It can't generate an independant display on its own, and instead the VNC server mediates communication with the OS 9 display over the network. (So if you are VNCing into an OS 9 box, your mouse movements on the "VNC side" makes the cursor actually move on the screen.)
So there's a precdent for VNC servers sitting on top of and not replacing a window server... can this be extended to OS X/Quartz? I have no idea.
It might take Apple's cooperation, though, and perhaps a lot of it. And of course, my thinking on this may be totally wrong. Does anyone who has done VNC work before know if this is a totally faulty idea?
Anyway, I'm going right now to nag Apple and tell them to make it easy to do a VNC Server for Quartz, just on the off chance that it is possible.
Zach
strobe
Puny Member
1) Incorrect. You can always encrypt any tcp stream. Apple will NOT have to design a new tool |-p
2) There are a few 3rd party PDF viewers. One could be converted into a remote PDF viewer. We already have display ghostscript for postscript, why not for PDF as well? (ghostscript can render PDF documents)
What makes you think a VNC-like solution would be faster than a PDF one?! The changes the Quartz output goes through are just as complex.
You can test your theory using Win32. It\'s not practical. You would be far better off converting ghostscript into a remote PDF viewer.
It isn\'t, and you can confirm it yourself. Please don\'t waste your time (and possibly Apple\'s)
scruffy
Notorious Olive Counter
I have read, can\'t remember where now, that Quartz has remote display capabilities buit in. Not that they\'re available right now, as of PB, and perhaps won\'t be as of 1.0, but that somewhere in the future, they could be.
Given that there is a reasonable separation between the apps and the window server/manager in OS X (unlike OS 6-9 ? ), it shouldn\'t be too difficult. VNC is horrid slow, as you all know, since it can\'t just send window events, but has to send all the pixel changes whenever you click a button, or whatever. Seems to me that since Apple have taken care to design everything with a good modular approach, remote execution might not be too difficult.
I have access to only one OS X box, but has anyone tried to ssh/telnet into one OS X box from another, and then open -a some program on the remote machine? I don\'t expect it would work, but the error messages, etc. might offer some insight into whether the architecture is there.
Also, anyone know whether there was some sort of similar ability with NeXT? Remote display on DPS should be at least a bit like remote display on DPDF, you\'d think.
Given that there is a reasonable separation between the apps and the window server/manager in OS X (unlike OS 6-9 ? ), it shouldn\'t be too difficult. VNC is horrid slow, as you all know, since it can\'t just send window events, but has to send all the pixel changes whenever you click a button, or whatever. Seems to me that since Apple have taken care to design everything with a good modular approach, remote execution might not be too difficult.
I have access to only one OS X box, but has anyone tried to ssh/telnet into one OS X box from another, and then open -a some program on the remote machine? I don\'t expect it would work, but the error messages, etc. might offer some insight into whether the architecture is there.
Also, anyone know whether there was some sort of similar ability with NeXT? Remote display on DPS should be at least a bit like remote display on DPDF, you\'d think.
strobe
Puny Member
Rumor has it DP3 supported remote display but I would have to re-install it to check.
NeXT had nxhost which follows the same concept as xhost except it piped postscript commands. The same could be done with PDF data.
It would work for Carbon and Cocoa apps (although not Classic).
NeXT had nxhost which follows the same concept as xhost except it piped postscript commands. The same could be done with PDF data.
It would work for Carbon and Cocoa apps (although not Classic).
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
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
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
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
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
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
Puny Member
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.
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.
Strobe, I've been waiting since you posted this:
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
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
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
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
Puny Member
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!
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!