[IDEA] shrink xrender featureset

Juliusz Chroboczek Juliusz.Chroboczek at pps.jussieu.fr
Tue Nov 25 13:16:16 PST 2008


> 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



More information about the xorg mailing list