> > http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators
Interesting. I found that the qcow format is slowing installation a lot. The filesystem spends more time growing the qcow disk than anything else. The raw format is faster. > > But in the case of SPARC-on-Qemu you should be able to use VNC > (specifically, Debian's vnc4server package), in conjunction > with FluxBox > as desktop/wm it's fairly lean and performs well. The machine > in front > of me is a (real) SPARC running Etch, thanks to your patches > 0.9.30+2.4.2 are now running fine on it so there's a fair chance the > same would apply to an emulated system; I'm in no great hurry > to update > this system to a later OS but am overdue for going round > everything and > getting onto 2.4.4. QEMU comes now with an integrated VNC server. The problem is that the OPENBIOS used for sparc supports only 8 bit or 24 bit color depths while the debian suntcx driver doesn't support 24 bits. Leaves the 8 bit which lazarus doesn't support. VNC doesn't change that. > > ARM is more of a problem since vnc4server is not ported to > it, I believe > that there are some ARM-specific problems in the VNC sources. > There's a > different server that does run on it (from memory, > tightvncserver) but > it appears to be hardcoded to expect the display manager to be xdm- I > prefer gdm since it's the only one with a reliable XDMCP > implementation. > The QEMU build in VNC server for arm works well but gives you the small resolution of the versatilepb board. > In either case you /should/ be able to connect to the system using > XDMCP, e.g. using Xnest on your local system and gdm+FluxBox on the > headless one, subject to your network setup since XDMCP is a > UDP-based > protocol which implies that broadcasts don't route well. On both arm and sparc I'm using XFCE which is quite lean also. I noticed very little difference in speed when running lazarus with X transported over ssh (no windowmanager running on the guest) or running in a windowmanager. The cpu time spent in ssh/sshd transferring the X packets roughly equals the cpu time spent by the window manager dealing with them. The advantage of ssh is the increased resolution/color depth. For the arm limited to 256M memory, not running a windowmanager gives you also more precious memory. > However at one > time (I don't know whether this is fixed) Lazarus and some other apps > performed very badly using networked X, my recollection is that the > consensus was that there was excessive input-device polling. > I noticed that the small hints that pop up when you hover over about anything are very costly. The cause a lot of painting and repainting. I just uploaded another patch for syneditmiscclasses.pp. When you cut a text in one unit and paste it in another unit a sigbus exception was thrown. A char pointer cast to an integer pointer. Ludo -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
