[haiku-development] Re: Haiku Font Rendering
- From: waddlesplash <waddlesplash@xxxxxxxxx>
- To: Haiku Development ML <haiku-development@xxxxxxxxxxxxx>
- Date: Fri, 9 Aug 2019 18:20:08 -0400
On Fri, Aug 9, 2019 at 5:48 PM chase rayfield <cusbrar1@xxxxxxxxx> wrote:
The value of just making something work
efficiently, even if it is a hack, seems to be lost on developers in
recent years.
So here's a question. Why do we need to spend our limited resources at
present on this kind of efficiency?
I occasionally do hear these complaints about Haiku not running on
systems with 256MB of RAM; but this really seems to mean "I don't want
to give my VM 256MB of RAM." What actual systems are you trying to run
Haiku on with 256MB of RAM? Because ... most of those are boxes from
the early '00s with really, really slow CPUs by modern standards, and
I think you'd want to avoid those purely for that reason.
A 130MB font is beyond ridiculous in all but a few
corner cases that would be better served by a locale specific font
anyway.
No. It is not. Having all locales serviced by one font, with one
consistent style, is actually more efficient here.
Further, the way FreeType renders fonts, the font file is itself
mmap'ed into memory. So on Haiku it will be backed by a VMCache, which
is the exact same system disk caches go through. So then when we have
a lot of memory pressure, the kernel will flush the VMCache's
non-dirty pages out of memory, which will impar performance but allow
the system to keep running. Nowhere near all 130MB of the font will be
loaded in at any one time, unless you are actually using all 200-odd
languages it supports.
You could argue that a 130MB font is a hack to a system that
assumes it is reasonable to be able to display all fonts from every
locale all at once.
"Every" locale? No. But PulkoMandy at least uses 3 of those languages
on his system, I believe. Other users may use any given number > 1.
Actually having separate fonts would be *less* efficient here, as the
overhead to have those loaded, mmap'ed, fontconfig'd, etc. would
likely be greater than the overhead of having a 130MB font.
The arguments against GPU acceleration are now dated and disproven and
there are several examples in the wild of it being done effectively.
We aren't arguing "against" GPU acceleration, we are saying it should
be largely unnecessary. I also note that the memory overhead for
GPU-accelerated rendering of anything, but especially fonts, is about
3-4x on *host* memory, not to mention GPU memory, vs. CPU rendering.
So this will help performance but not memory usage. Nor does it have
any relevance for the situation at hand, because all of this requires
programmable GPUs of the "GCN" era or their Intel/NVIDIA equivalents,
so about 2009 or so at the very least. I don't know of many systems
from 2009 with < 1GB RAM, or ones that cannot handle FreeType, so
again I don't know how this is relevant at present.
Certainly we need to let the myth that GPU rendering must
necessarily be slower than GPU rendering... there is too much to gain
(at least an order of magnitude in performance) from taking advantage
of the GPU to continue architecting things without the GPU in mind.
Nobody said there was not. But there definitely isn't for these "256MB
RAM" systems that we were talking about here.
The other problem is that CPUs are much farther way from the screen
than they used to be...
[[citation needed]], especially seeing as 80+% of pixel drawing on
Linux is still CPU.
-waddlesplash
Other related posts:
