On Sun, Mar 21, 2021 at 07:55:06PM +0800, Qian Yun wrote:
>
>
> On 3/20/21 2:20 AM, Waldek Hebisch wrote:
> >
> > We need some graphic environment. Simple fact of life is that
> > up to now X11 was most stable environment. Namely, old 30
> > years old programs work as they used to work. Unfortunatly,
> > this is not the case with newer things, my graphic code
> > for "famework of the day" got broken in few years. And a lot
> > of folks have similar experience.
>
> If X11 becomes obsolete (let's say 20 years later), would you
> agree to include another graphic framework into our repo?
There is misunderstanding here: you do not need to wait
to include another graphic framework. My impression
was that I am not the main opponent of new code in
FriCAS: when new code was proposed sometimes other
folks voiced strong objections...
Concerning what I look at:
- first, code must be useful and of resonable quality, this
is not a high barrier and quite natural
- build and dependencies: FriCAS should build cleanly with
new components added. New mandatory dependency requires
quite string justification. Optional dependecy, say when
you disable new component when dependency is not present
is OK. However, with optional dependecy the component
itself becomes optional and core parts can not depend on
its presence.
Having said that, much of power of system comes from
cooperation, that is how well various components play
together. There is scenegraph subsystems by Martion
Baker. AFAICS it is underutilised. At leat for me
major obstacle in using this subsystem is that it
lives in its own world, with rather narrow connection
to other graphic components in FriCAS. I have
rather detailed opinions about what develepements
would be most useful for FriCAS, but ultimately
people who write code decide what gets written.
Different matter is removal of code. While I like
to remove dead code, when removing functionality
I am more careful. For example, I mostly use
HyperDoc and make almost no use of ')show'. But
I do not propose removal of ')show'. Paraphrasionig
what what said about HyperDoc in other messages
somebody could say: "HyperDoc is now supported on
all our platforms, so ')show' can be removed"
(on Windows one can get HyperDoc via Cygwin or WSL).
There were proposed patches which removed some
functionality on principle that is is easier
than keep code working. This can be valid argument,
but only rarely (and most that should be removed is
already removed).
> > Let me add that retargetting our existing programs say to
> > WinAPI would be rather easy (and would not require breaking
> > X11 support), but nobody voluntereed to do the work. It
> > seems that people prefer to work on new code, probably
> > because in new code they can concentrate on core things
> > and (at least at beginning ignore some system aspects and
> > corner cases). But for long term interface it is exactly
> > handling of system aspects and corner cases that determines
> > viablility. Adapting tried code in very slowly evolving
> > environment is much easier than coping with rapid breaking
> > chages in "modern" systems.
>
> I don't think there are many "corner cases" get improved in
> HyperDoc in the past 20 years? Probably because it doesn't
> attract many users, thus fewer developers.
There is a buch of fixes on C side. More important, large
(one can argue that main) part of HyperDoc subsystem is
in written in Boot and included in FRICASsys. This part
got a lot of fixes and cleanups.
> > Another apect is performace: our X11 programs have by
> > current standard very small resource requirements and
> > high performace. Browsers (and web page code) tend to
> > get slower faster than hardware get faster so for
> > long time we can expect bad performance.
>
> No modern GUI toolkits can beat X11 in terms of low RAM
> usage. (But it can beat X11 in performance by using
> GPU rendering in some cases.)
>
> I would say X11 programs has its own list of disadvantages:
> 1. Security. (One reason it is getting replaced by wayland.)
I am not aware of security problems specific to X11. AFAICS
main problem is that X subsystem is large piece of code dealing
with sensitive data. IMO any GUI will have the same core
problem. Of course, new implementation can take advantage
of past experience and avoid known problems. But the
unknown problems are main issue. Also, new design/implementation
usualy starts from mainstream applications. That frequently
can by done by simpler approach than general case. To
be more specific IIUC Android proposes new security regime,
supposed to be much safer than trandtiononal Unix way.
But my understanding is that many everday activities does
not fit well into Android model, either depriving users
of functionality or needing holes in security model.
So, IMHO before Wayland gets enough testing it is premature
to make security claims.
> 2. Performance. Because rendering using CPU is much slower than GPU.
X11 has extentions. Direct access to acceleration functions in
cards was available for many years. More important, for majority
of normal programs is rendering is fast enough. And rendering is
mostly handled by library/X server code, so once distribution is
updated it will automatically use whatever acceleration is
available. Of course, programs like games must be aware of
extensions and use them.
> 3. i18n. I don't think X11 libs can do truetype fonts and RTL languages?
IIRC from the start X11 had framework for internationalization.
Of course, it depends on vendors/distributions how well they
use that framwork. For example it took long time to get widely
distributed Unicode fonts (but it is not problem of X, but
availability of fonts). In particular, in traditional X way
all applications had to do was to choose appropriate font
names. IIUC problems with truetype fonts was/are mostly legal
(my understaning is that free implementations are not allowed
to support "hinting") and that limited availability, X can use
them if included in build. There is also "new" trend that
moves fonts to client side. I am not sure how much impact
this have.
Anyway, by design X11 protocol is extensible and new features
my be supported by extensions or appropriate conventions.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210321164935.GB15769%40math.uni.wroc.pl.
