Re: Radical idea for X-modmap problem.
>> (Nowadays, the servers are fairly ordinary PCs running Linux, with >> a few Solaris machines to make the older system administrators >> happy.)... > (I'm afraid to ask how old is 'older'.) (Grad students, maybe?) Most students don't care, as long as they get whatever userspace tools they need to do their coursework; the ones that do care (Ubuntu fans, mostly) bring their own laptops to practicals. It's the system administrators who tend to have strong preferences. > I'm wondering about the connection from terminal to server, and how much > bandwidth would be typical for such a setting. 100Mbit switched ethernet is fine (native X, not compressed), as long as the latency is low enough. In the departments I know, however, this model is slowly dying out. Now that fairly powerful fan-less PCs are available at a reasonable price, we've been migrating to netbooted, disk-less workstations (root mounted over NFS). This makes it possible to use things like Eclipse, which would overwhelm the centralised servers. > (I'm assuming that college students would spent substantial time > watching X-rated videos on their X-terminals ;-) Our students lead fulfilling lives, and have no need for the cheap ersatz of a sex life that is provided by commercial erotica. And they've all got ADSL at home nowadays ;-) Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
> Being strictly an amateur programmer, I've always wondered how many > people/institutions actually use X for remote display the way it was > designed to be used. Quite a lot. In universities in crowded city centers, it is quite common to have students work on (fan-less) X terminals, with a large server pool hidden somewhere in the basement. (Nowadays, the servers are fairly ordinary PCs running Linux, with a few Solaris machines to make the older system administrators happy.) A lot of us also prefer ``ssh -X'' to webmail and other workarounds. > Seems to introduce a great deal of confusing complexity for features > many of us never use. OTOH, having a well-defined interface between the display subsystem and the rest of the system forces us to keep our interfaces clean. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Bug in Xextproto
> INT32 type (and incompatible ones even, since Xmd's is unsigned long on > ILP32 because whoever wrote Xmd.h is a C novice). How quickly they forget... When I was but a lad, we wrote ``long'' whenever we used values that could be larger than 32767. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> Wasn't the reason to do font rasterization primiary to give applications > more control over font rendering? If memory serves, Keith was trying to find a design to solve both issues with core fonts -- lack of flexibility and latency. There was an extended brain-storming session on the old XFree86 list (Keith, Ralf, Rob Pike, myself, probably others I forget), and suddenly there was this collective insight -- client-side rasterisation solves both problems in an elegant way. > After all isn't that just an implementation problem of the xserver? The fact that other clients are locked out during font rasterisation is. However, it's tricky to fix -- it basically requires either threading the server, or converting your font rasteriser to continuation-passing style. The fact that fonts cannot be rasterised incrementally but must be fully rasterised at font open time, on the other hand, is a design flaw of the core fonts mechanism. (Due to the fact that the core protocol requires providing accurate ink metrics at font open time.) > When doing e.g. gradients client-side, all hope for hw accaleration is > lost, furthermore it would mean transferring a _lot_ of data between the > client and the server which would pretty much kill network performance. > Furthermore it would lead to more frequent syncs (when shm is used) or > increased copy-overhead (when going through protocol). In no way am I claiming that client-side gradients are the right solution. I'm simply saying that the client- vs. server-side debate is seldom as clear cut as a previous speaker made it, and that the pros and the cons need to be carefully weighted. My personal instincts tend to go towards client-side operations whenever possible -- every complex server-side operation I tend to see as a failure to design the right protocol-level abstractions. As far as network and SHM performance -- Keith convinced me at some point that we don't currently have a good pixmap transport extension. I'd like to see something that uses a windowed, non-blocking form of SHM when working locally, and some smart compression method when working remotely. (There's no reason why the compression mechanism shouldn't have an ad-hoc encoding for gradients, if gradients are found to be important.) Point taken about hw acceleration, although I happen to think (or hope) that hw acceleration of 2D graphics is going the way of the dodo. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA and migration
>> Apparently, the current incarnation of EXA is built on the assumption that >> everything should be accelerated, and that when it isn't, it's a bug. Hence, >> it pays no attention whatsoever to the performance of software rendering. > That's not 'strong vocabulary' but simply baseless flamebait. Sorry if you took it that way. I think you'll agree that current incarnations of EXA do some rather silly things when some, but not all operations in a sequence can be accelerated. Since some rather smart people are working on EXA, I have trouble understanding why this rather obvious shortcoming. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> Well if you let me decide between software rendering on client or > software rendering on server, I would prefer the latter. It's not that clear cut. At least some of the motivation behind Render is about moving time-consuming operations into the client, notably font rasterisation. There are two reasons why you may want to move stuff into the client. One is flexibility: for most users, it's easier to install a new version of a library, than a new version of the X server. This was the principal reason why Render moves font rasterisation into the client. The other point is that having time-consuming operations in the server increases client latency. Before Render, all font rasterisation happened in the server, and this would cause noticeable pauses (with the whole server frozen, not just a single client). While it is possible to implement background processing in the server, using ``Block Handlers'' (that's how I implemented the now-deceased XFree86 DPS extension), it's difficult, error-prone, and there are just three people in the universe who know how it's done. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
EXA and migration [was: shrink xrender featureset]
> Sorry just to clarify - can't Xorg draw a gradient directly to the pixmap > over PCI, rather than migrating the pixmap out of the video card? We've been flaming on this subject on this list before. Apparently, the current incarnation of EXA is built on the assumption that everything should be accelerated, and that when it isn't, it's a bug. Hence, it pays no attention whatsoever to the performance of software rendering. (Strong vocabulary chosen deliberately, to get some EXA expert to react.) Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Rotating X Fonts?
> 1. Is there a way to know at run-time whether or not an X-server will > actually be able to honor the rotated font request? Not officially. However, you may have a look at the font property ``RASTERIZER_NAME''. If it says ``FreeType'', ``X Consortium Type 1 Rasterizer'' or ``X Consortium Speedo Rasterizer'', it will probably work. If it's something else, all bets are off. > 2. Is there any documentation/standard for the use of rotated fonts, > e.g., the name of the rotated font above is mostly a mystery between > the []? The XLFD spec, version 1.5, Section 4. http://www.x.org/docs/XLFD/xlfd.pdf > 3. I suspect the issue might be a discrepancy between the installed > fonts on the two X servers. No, it's more probably a discrepancy between the font backends being used. I suspect that Hummingbird uses a rasteriser called the ``X Consortium Bit Scaler'', which has been disabled in X.Org. Core X11 fonts are deprecated in X.Org. I strongly recommend that you switch to Xft, which doesn't have any of these issues. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
>> Thanks for the info. Will be nice if someone can quickly tell any pros >> and cons of using kdrive instead of Xorg, > Pros: pretty much none. Cons: it's not Xorg. Pros: it's easier to understand and to work with. it doesn't have the module loader. Cons: it doesn't have the module loader. it doesn't do acceleration as well. it's not supported as well as X.Org. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
>> glibc chews up what, twenty megabytes? > > [citation needed] $ dpkg -s libc6 locales | grep ^Installed-Size: Installed-Size: 11452 Installed-Size: 11752 Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transient windows
> behind the transient principle, the documentation that I've found is > light and examples aren't many on the web or won't go too deep into the > matter. I don't know if you have any link to suggest me, if any, I'd be > glad. ICCCM, Section 4.1.2.6. The ICCCM is a complex matter, and most tutorials you'll find on the subject are incorrect. You really should read the ICCCM (as well as the freedesktop.org wm-spec) rather than trying to browse the web for information. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pixman with and without SSE2 benchmarks?
> There is a summary of the performance difference compared to the MMX > code: > > http://www.daimi.au.dk/~sandmann/perf-diff (Twice as fast on many benchmarks.) Note that this is on core 2, which has magnificent SSE performance. I haven't tried it, but I'm willing to bet that on Pentium-M and Pentium 4, the results are similar for SSE and MMX. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
