Re: Draining the font swamp

2007-05-21 Thread Phillip Susi
Matt Zimmerman wrote:
 - Xfont, which provides font services (including selection and rendering)
   through the X server.  This is basically obsolete in favour of client-side
   fonts.

Why is this?  Client side fonts are bad for several reasons:

1)  You end up with the mess you point out, where you have several 
different client side font systems.

2)  That leads to code that is harder to maintain and configure and 
troubleshoot.

3)  Performance suffers.  The X server is in the best position to render 
fonts using any hardware acceleration provided by the video card, and 
allows for those fonts to be shared by all applications, reducing 
duplication and waste.  Also for remote X sessions, you want the fonts 
rendered on the server so much less data needs exchanged between the 
client and server.

Other than the fact that the client side implementations have advanced 
beyond the X server ones in recent times, is there any advantage to 
client side font rendering over server side?  If not, then we should 
push to bring the client side advancements back into the server where 
font rendering belongs.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Draining the font swamp

2007-05-21 Thread Matthew Garrett
On Mon, May 21, 2007 at 10:52:46AM -0400, Phillip Susi wrote:

 3)  Performance suffers.  The X server is in the best position to render 
 fonts using any hardware acceleration provided by the video card, and 
 allows for those fonts to be shared by all applications, reducing 
 duplication and waste.  Also for remote X sessions, you want the fonts 
 rendered on the server so much less data needs exchanged between the 
 client and server.

Measurements have shown that over pretty much any sort of common 
network, latency is more of a problem than bandwidth. Server-side fonts 
require multiple round-trips between the server and the client for 
rendering, whereas client-side fonts only require the initial display. 
Performance-wise, we have the XRender extension for precisely this sort 
of situation.

 Other than the fact that the client side implementations have advanced 
 beyond the X server ones in recent times, is there any advantage to 
 client side font rendering over server side?  If not, then we should 
 push to bring the client side advancements back into the server where 
 font rendering belongs.

Font choice and layout is hard, and doesn't become any easier just 
because you've moved that code to a binary that runs as root. Nobody is 
going to argue in favour of putting a layout engine like Pango in the X 
server, and most of the rest of the stack is similarly well outside the 
scope of the X server. The client-side font revolution happened 5 years 
ago, and we've ended up with massively improved font support as a 
result.

-- 
Matthew Garrett | [EMAIL PROTECTED]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: ReadyBoost Technology for Ubuntu and Linux

2007-05-21 Thread Oystein Viggen
* [Florian Zeitz] 

 Linux has been able to do this for ages, but it has been considered a
 bad idea, because it wears the memory sticks flash.
 In theory all it takes is:
 1. # mkswap /dev/sdX (where sdX is your memory stick)
 2. Edit your fstab to say:
 /dev/sdX none swap sw,pri=2 0 0
 UUID=stuff none swap sw,pri=1 0 0
 instead of
 UUID=stuff none swap sw 0 0
 3. # swapon -a

Then again, this is nothing at all like ReadyBoost.

What ReadyBoost apparently does is to use the flash drive as a secondary
disk cache (note: disk cache, not swap) for often read, rarely written
data.  The point being that while the disk can deliver 50MBps and the
flash drive can only deliver maybe 20MBps, you still read a 4k block of
data faster from the flash drive because the much lower seek time makes
up for the lower sustained data rate.

Of course, the most read data will be present in the disk cache in RAM
anyway, so ReadyBoost only provides an advantage for not-quite-as-often
read data, or maybe during boot.  It is also quite clearly more
beneficial (except maybe during boot) to add the same amount of RAM
instead of ReadyBoost flash drive to your system, but 2GB flash drive is
cheaper than 2GB RAM.

There's also little reason to think that this needs to wear out the
flash drive very quickly.  If you store system files (or more correctly,
blocks from system files) like the contents of /bin, /lib, /etc, and
most of /usr, these are files that hardly ever change (except during
dist-upgrade or the occasional security update), but still represent a
lot of small reads and would as such benefit from being read from a 1ms
seek time flash drive instead of a 10ms seek time hard drive.

To answer the original question, I've not heard of anything like
ReadyBoost for Linux.  Googling for it, I mostly find explanations from
people who did not understand ReadyBoost, and present solutions like the
one I quoted.

Øystein
-- 
Outgoing mail is certified Virus Free.
..of course, the virus would tell you the same thing..


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: ReadyBoost Technology for Ubuntu and Linux

2007-05-21 Thread Sven
Am Montag, den 21.05.2007, 19:32 +0200 schrieb Florian Zeitz:
...
 I think it might be worth implementing if done properly (it seems using
 ReadyBoost in it's current form in Vista can actually slow down the
 system sometimes).

The technique to slow down your computer and waste sticks for some
milliseconds will not go into the linux kernel i guess.
http://www.google.de/search?q=20060090031

But i think harddrive manufacturers will build in larger caches doing
the same job much better.

regards, Sven



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Draining the font swamp

2007-05-21 Thread Scott James Remnant
On Mon, 2007-05-21 at 15:09 -0400, Phillip Susi wrote:

 How does server side fonts require more round trips?  It should amount 
 to a single message that specifies what font to use, what text to 
 render, and where.
 
Only after a detailed exchange to determine the character-set coverage
of the font in question, and to perhaps request additional fonts to
cover those characters that are missing; then to calculate the metrics
of the font to see whether it will fit into the assigned area, and
perform word-wrapping (each requiring more metric checking round-trips).

Lots of back-and-forth.

 With client side fonts, the client has to have the fonts in the first
 place, then has to render them
 
The server has to both of these too, so it doesn't matter which side you
put the having or the rendering.

 then send them as a bitmap to the server.  If you want to do things like
 anti aliasing, then the client has to read a bitmap from the server, then
 render the font into it, then send the resulting bitmap back to the server.
 
Not true.  This is what the Xrender extension is all about.  The client
just needs to send the rendered font, which may in fact be a series of X
protocol (or GL, etc.) drawing commands.  At the worst, it'd be a
transparent pixmap.

Just one send, regardless.

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: ReadyBoost Technology for Ubuntu and Linux

2007-05-21 Thread Jonathan Jesse
On Monday 21 May 2007 13:32:46 Florian Zeitz wrote:
 Oystein Viggen wrote:
  * [Florian Zeitz]
 
  Linux has been able to do this for ages, but it has been considered a
  bad idea, because it wears the memory sticks flash.
  In theory all it takes is:
  1. # mkswap /dev/sdX (where sdX is your memory stick)
  2. Edit your fstab to say:
  /dev/sdX none swap sw,pri=2 0 0
  UUID=stuff none swap sw,pri=1 0 0
  instead of
  UUID=stuff none swap sw 0 0
  3. # swapon -a
 
  Then again, this is nothing at all like ReadyBoost.

 I'll have to admit that I now know that I know nothing.
 Back when I wrote the message you quoted all articles I had read about
 ReadyBoost said it was just swapping on flash drives.
 Right now after doing some research I'm a bit confused, because most
 sites contradict each other.
 It seems that ReadyBoost is actually a cache for about everything from
 swap file over system data to often read user data.
 I think it might be worth implementing if done properly (it seems using
 ReadyBoost in it's current form in Vista can actually slow down the
 system sometimes).


I've been suprised about how little even people who work w/ MS products every 
day really understand ReadyBoost.  In one of the recent issues of Microsoft 
Technet magazine, I don't have it in front of me, but Mark from SysInternals 
fame has written a really good article about it.  

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Draining the font swamp

2007-05-21 Thread Ming Hua
On Mon, May 21, 2007 at 01:13:56AM +0100, Nicolas Spalinger wrote:
 
  - Whether we still need all these horrible bitmap fonts
 
 You mean the fonts available in the x-fonts* packages?

I think the names are xfonts-*.

Last time I checked, X server won't start without the fixed bitmap
font from xfonts-base.

 I would suggest a poll on usage and possible demotion to universe or
 specific langpacks. Might be different for CJK fonts.

I believe the general consensus among Chinese users is that bitmap fonts
are preferred for small font size.

There is a technique called embedded bitmap that can put bitmap fonts
of different size into a TrueType font, and libfreetype handles this
correctly.  There are currently one set of fonts (with two typefaces) in
Debian/Ubuntu that has embedded bitmaps.

A sad thing, however, is that although there is a group actively working
on a set of Chinese bitmap fonts and has improved the quality quite a
bit, their work can't be embedded into the existent TrueType font due to
licensing restrictions.  So I am afraid in the short term stand-alone
bitmap fonts are still necessary for Chinese users who are picky about
font rendering.

Ming
2007.05.21

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss