From: Digital I. Inc. <ok...@di...> - 2004-05-18 08:58:52
|
>On Tue, May 18, 2004 at 06:34:56AM +0900, Digital Infra, Inc. wrote: > >> Yes, tweaking conet is one goal. >> but I suppose that it is not the only way for X performance improvement. >> I guess that by using named pipe (or shared memory or ,, anyway, one of IPC funcs) >> of NT, You can make "direct path" between Cygwin/X server and X client on coLinux. > >I have looked over the interfaces provided by a Linux 2.6.x frame buffer >driver, and it looks very feasible to implement a frame buffer for coLinux >once we get the 2.6.x port working. In the frame buffer mode, we wouldn't >pass actual bitmaps in any pipe, so it's going to be almost as fast as >the native. > Yes, even 2.4 kernel, supporting frame buffer is easy. and we dont have to stick to only Linux FB, but also DirectFB or SDL or whatever. so just making bitmap appeared is easy. the problem is, how much we can utilize GDI acceleration and how to support " -multiwindow" option of Cygwin/X. another point is, how to support Japanese. I mean, current X font renderer has two problems for Japanese. it can show Japanese, but quality is the problem. one is renderer quality itself. second is font. the easiest way is using Windows function and fonts. and this is one of the reasons I stick to Cygwin/X. maybe if once Linux FB approach becomes popular in coLinux, I would make X font server on Cygwin for coLinux. although I currently dont know what X does about font, but it would be like this: Windows TT font -> Win32 font renderer -> XFS on Cygwin -> conet -> coLinux -> X server -> FB -> Windows GDI umm.... a little bit complicated... >> but before starting this hack, we have to make it clear the difference >> between Cygwin/X and VNC. >> I think if we succeed to add reconnect func to Cygwin/X, Cygwin/X would win. >> I have been working on researching about feasibility of it. > >BTW, are you aware with the problem of distributing Cygwin with anything? >There's this DLL shared memory issue (i.e version conflict). I suggest we >either compile XFree86 on MingW or find another solution. > you found some problem? really? it runs on my PC normally. I already succeeded to run Cygwin/X without installing whole cygwin. the problem is, I can not remember that what I did to run it ;). once I reproduce the whole install procedure, I can make Cygwin/X installer for conoppix. >> BTW, why VNC and Cygwin/X have almost same performance currently? >> I dont understand the reason totally. Cygwin/X can use Win32 GDI directly. >> and it must be much faster. >> additionaly, VNC does " X -> VNC(RFB) tiled encoding -> X " protocol conversion. >> I guess that this should be also big overhead. >> but I have to admit that we fell both way has almost same performance. why??? > >The reason that VNC is faster is the round trip time. Most X requests are >synchronous across the network. Compare launching xemacs for instance - >it contains a lot of screen updates when it's going up. If you let it go >up on a local X server and then sample the screen asynchrounously every >once in a while, it will load much faster. > Good suggestion. but I think it is just a phychological effect. of course it is important issue, but real performace is also important. what X server does is almost same on both Linux local and Cygwin. and we have three ways of using X. VNC, Cygwin/X and Linux FB. and the difference is like this: - conet overhead. Cygwin/X and VNC suffers from conet overhead. but this could be reduced when conet gets improved. and we can even add "direct path". - GDI acceleration. in the long run, probably this is the key. for this point of view, VNC would lose. - phychological effect. yeah, this is also important. --- Okajima. |