|Subject:||Re: Package building|
|Date:||Wed, 20 Nov 2019 02:37:21 +0200|
|On 19 Nov 2019, at 10:03, Fred Kiefer <address@hidden> wrote:|
You’re right. Actually libart absence is only part of a problem. I’ve had to compile LLVM/clang 7 for CentOS to use libobjc2 and modern Objective-C features. Now RedHat threw out libart from CentOS/RHEL 8. I suppose it’s not a problem for other distributions.
This is not that simple question, but I’ll try to explain. Please be aware that my explanation is: subjective and hard to prove with numbers right now. Also my _current_ goal is to create NeXTSTEP-like desktop with minimal changes to GNUstep libraries.
There’re 2 main reasons for using art backend:
1. Speed. Terminal application “feels” faster with art versus cairo. I suppose it’s due to text rendering implementation (some tricks?). I can restore benchmark from original Terminal.app and send you a results. With art backend graphics exposures appear less often (no flickering). I guess art backend uses some buffering/caching for window portions. Remember I sent PR to fix flickering of appicon that is visible with cairo backend but not with art. To be fair, this is good attribute of cairo backend (we’ve optimised app icon drawing as a result) and image drawing with cairo looks better (for example, scrolling of NSImage much faster/smoother).
2. Font bundles(.nfont). As a font packager I can specify drawing properties (RenderingHints_hack), font name, other font properties (traits, weight, localised names, etc.). As a user I like the ability to drop font into Fonts directory have font available for applications and looking right (as package maintainer/creator think it should look). I know about fontconfig settings - I’m talking about separate GNUstep-only font packaging.
I guess, these to 2 things will be able to fix/implement. Unfortunately, I don’t have time to do it right now.
|[Prev in Thread]||Current Thread||[Next in Thread]|