[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rethinking the design of xwidgets
From: |
Eli Zaretskii |
Subject: |
Re: Rethinking the design of xwidgets |
Date: |
Wed, 14 Oct 2020 18:32:48 +0300 |
> From: Arthur Miller <arthur.miller@live.com>
> Cc: Akira Kyle <ak@akirakyle.com>, emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 17:04:07 +0200
>
> In case where there is a discret gfx card (i.e. Nvidia/AMD) it is
> probably faster to send everything to GPU and ask it to render a
> giant texture and then use it as XWindow pixmap, or something similar
> then to figure out on CPU all the stuff that should not be displayed.
I believe this should be the job of the GUI library we use (Xlib etc.)
> But Emacs will maybe run on some slow devices (atmel Emacs anyone?), so
> you probably don't want to ditch away all that disp stuff.
Different Emacs configurations could employ different redisplay
optimizations, if we know which ones are necessary when.
> > We try not to use machine-dependent code in Emacs, because that's a
> > maintenance burden, what with today's fast pace of chip development
> > and obsolescence. Vectorization is generally left to optimizing
> > compilers, and relying on special hardware, such as GPU, is not
> > something we should depend on directly. We should instead hope that
> > the GUI toolkits and display systems we use will do that for us.
> Would it be considered too machine-dependent if you rendered into
> off-screen OpenGL surface as your rendering target? Should be avialable
> on Nvidia/AMD/Intels gpus. With offscreen egl you would have relatively
> OS independent code too; but that would require explicit linking to
> proprietary libs. I mean X11/Win32 already does that when proprietary
> drivers are installed, so Emacs (and any other software) "implicitly"
> links to those, but I don't how it is viewed if you would to explicitly
> when present.
Why should we do that in our own code, as opposed to using some
higher-level library?
- RE: Rethinking the design of xwidgets, (continued)
- Re: Rethinking the design of xwidgets, Eli Zaretskii, 2020/10/13
- Re: Rethinking the design of xwidgets, Basil L. Contovounesios, 2020/10/13
- Re: Rethinking the design of xwidgets, Eli Zaretskii, 2020/10/13
- Re: Rethinking the design of xwidgets, Akira Kyle, 2020/10/13
- Re: Rethinking the design of xwidgets, Eli Zaretskii, 2020/10/14
- Re: Rethinking the design of xwidgets, Arthur Miller, 2020/10/14
- Re: Rethinking the design of xwidgets,
Eli Zaretskii <=
- Re: Rethinking the design of xwidgets, Arthur Miller, 2020/10/15
- Re: Rethinking the design of xwidgets, Kai Ma, 2020/10/17
- Re: Rethinking the design of xwidgets, Qiantan Hong, 2020/10/17
- Re: Rethinking the design of xwidgets, Stefan Monnier, 2020/10/14
- Re: Rethinking the design of xwidgets, Aiko Kyle, 2020/10/14
- Re: Rethinking the design of xwidgets, Arthur Miller, 2020/10/15
- Re: Rethinking the design of xwidgets, Akira Kyle, 2020/10/15
- Re: Rethinking the design of xwidgets, Arthur Miller, 2020/10/15
- Re: Rethinking the design of xwidgets, Richard Stallman, 2020/10/16
- Re: Rethinking the design of xwidgets, Arthur Miller, 2020/10/16