[haiku-development] Re: Haiku Font Rendering

  • From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 09 Aug 2019 18:40:30 +0000

9 août 2019 17:04 "chase rayfield" <cusbrar1@xxxxxxxxx> a écrit:

Pulkomandy sounds like you need a higher resolution display ;-) 2k/4k
is mostly not that useful but small fonts would be an exception to
that rule.

On 2k/4k displays, there is no need to play tricks with subpixel rendering,
pixels are already small enough.

With the current system (which has a slider to adjust the amount of colors
used in the subpixel), I could finetune the rendering to my taste and
according to my display as well (since we don't do color profiles...)


Conversely, currently the Haiku installer also seems to require
loading all fonts some of which are quite huge, there's recently been
some back and forth over some of the larger fonts which I don't think
was ever resolved...it increases the memory requirements of the
installer past what is required normally to boot and probably slows
the installer down also, if anything the installer should be more lean
since swap isn't available... perhaps the loading of fonts could be
completely skipped initially and prerendered menu selections for
Language could be used to circumvent this? 

This is a ugly hack. If there are performance problems we should solve
them for all apps, not specifically for Installer.

Then only load required
fonts to the machine. Also you'd think the installer wouldn't load
all packages on the install disk unless live desktop was selected but
I'm not sure that is the case. I've always found the package selection
list in the installer quite weird since it doesn't work I think I have
a bug report about this also, It would be nice if it actually listed
all packages to install and allowed deselecting them intelligently by
category or groups. For instance if I want to build a minimal USB boot
disk or a subset of the install from a current install I can't do that
but it should be reasonably easy to do.

There is indeed a bugreport about this, no one was interested in working
on it so for beta1 we had just hidden that package selector. If no one is
still interested in implementing this, we will do the same in beta2.


Also, fancy font rendering is relatively slow on old machines, would
it be possible to provide BeOS equivalent font rendering for old PCs
or perhaps document graphics cards that can accelerate rendering
adequately on old machines. Perhaps the font menus should indicate
that one method or other is fastest or best quality etc... This may
be relevant for alternate architectures also that are slower than x86
or don't have an equivalent to SSE existent or implemented etc...

We have disabled hardware "accelerated" rendering when we found out it
was indeed slower than using the CPU. Basically there are 3 cases:

- PCI based hardware (very old!): the video card runs at 66MHz (PCI bus speed),
so any transfers to and from it are super slow.
- AGP based hardware (old!): writing to the card is much faster, but reading
isn't. AGP is a bus designed specifically for video cards, so it is expected
that you would send a lot of data to it, and let it process that on its side
- PCI Express hardware (what we have today): these card don't provide any 2D
acceleration anyways. They do only 3D.

BeOS made good use of the video hardware in the early days when the CPUs were
running at 1, 2, or 3x the PCI bus speed (66, 133, or 200MHz). But with CPU
commonly being in the Gigahertz range, this stopped being interesting to do.

We don't plan on going to hardware were disabling antialiasing would be useful.
Run the original BeOS there, it will do better :)

-- 
Adrien.


Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 08-2019