drl@vuse.vanderbilt.EDU (02/15/91)
How much does it cost to run X11 under SunView? It seems that, to a naive user accustomed to using SunView, it is not unreasonable to try to run X11 while within the SunView environment. In order to support this sort of usage, I defined the UseSunWindowsInServer macro in the sun.cf file. As the world shifts away from SunView, I wonder how much of a penalty the raw X11 users are paying for the naive users to use X11-within-SunView. Do anyone have a handle on this cost? If I decided to support both usages, would it require anything more than 2 Xsun programs (Xsun.sunview and Xsun.nosunview) and some logic in startx to pick the correct server? David
mouse@lightning.mcrcim.mcgill.EDU (02/16/91)
> How much does it cost to run X11 under SunView? > It seems that, to a naive user accustomed to using SunView, it is not > unreasonable to try to run X11 while within the SunView environment. > In order to support this sort of usage, I defined the > UseSunWindowsInServer macro in the sun.cf file. As the world shifts > away from SunView, I wonder how much of a penalty the raw X11 users > are paying for the naive users to use X11-within-SunView. Well, a "raw X11 user" wouldn't be running X under SunView anyway, so the only cost would be a little unused code in the server. Running X under SunView pays a little more penalty, but not much. There is of course the penalty of having all the SunView stuff lying around in memory all the time; if memory or swap space is short, this can be significant. All output is drawn directly on the frame buffer; SunView does not affect this. Input under SunView does come through SunView; this will of course affect things, though I suspect it won't be by very much, since so much of SunView is kernel-based. > If I decided to support both usages, would it require anything more > than 2 Xsun programs (Xsun.sunview and Xsun.nosunview) and some logic > in startx to pick the correct server? Not even that. Xsun built with UseSunWindowsInServer set to YES works just fine even when you're not running SunView. (It checks whether WINDOW_PARENT is set in the environment to determine whether it should do its SunView shenanigans.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (02/18/91)
>There is of course the penalty of having all the SunView stuff lying >around in memory all the time; if memory or swap space is short, this >can be significant. Note that, as of SunOS 4.0, it should, I think, be possible to remove that stuff from the kernel, if you're a "raw X11 user" running the MIT server or a derivative thereof. Try leaving the "pseudo-device winN" and "pseudo-device dtopN" lines out of your kernel; do *NOT* remove the "pseudo-device msN" or "pseudo-device kbN" lines out, because Xsun opens "/dev/kbd" and "/dev/mouse" and reads from them. Unfortunately, the Open Windows server always reads its keyboard and mouse events from the SunView kernel window system code, so it has to be there if you're running Open Windows. It does so in order to let you run SunView programs "on top of" (both figuratively and literally) X11/NeWS. What it *should* do is to try opening "/dev/win0" or whatever and, if it fails, fall back on using "/dev/kbd" and "/dev/mouse"; that way, it can run on systems with SunView kernel support, and allow SunView applications to run, but also run (albeit without allowing SunView applications to run) on systems without SunView kernel support.