emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Motif support


From: Arthur Miller
Subject: Re: Motif support
Date: Thu, 23 Dec 2021 13:15:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Ok. Thanks for confirming. By the way, what is the reason? Maybe they
>> have implemented the functionality they needed? Is it considered
>> complete?
>
> No, it's because their last user (GTK+) has stopped using Cairo in its
> latest release, replacing it with a custom alternative that can only be
> used with GTK.
Ok. Thanks.

>> Hardware acceleration only on X is fine. Win32/Mac are proprietary
>> OS:s, so if Cairo does support gpu acceleration on those, I think it
>> is fine. Current Emacs does not use gpu acceleration anyway (more than
>> what OS uses to render windows), so I don't think it is a major issue.
>
> Emacs does use GPU acceleration on every supported platform, as long as
> that is present.
Than we are not talking about same thing here. Of course every OS window will
use gpu if it's present. I meant using something like opengl or other terms to
render stuff ourselves not via OS.

>> I can only speak for win32, since I have never owned a mac machine so
>> have no idea how it works overthere. It is PITA if you gonna compile
>> Cairo on Win32 yourself from the sources because you have to chase and
>> compile all the deps, glib, libxm2 and co and so on. But it is not
>> PITA if you install precompiled one, or ou choose to install it via
>> MSYS2 which is as simple as intalling it on Arch Linux. Anyway, it
>> wouldn't be problem for Emacs, Emacs does not include Cairo sources,
>> and even if you prefer to compile it yourself, since Emacs is build on
>> MSYS2 (is cygwin officially supported?), building Cairo is just one
>> command line away, just as in gnu/Linux, so I don't think it is PITA.
>
> [..]
>
>> Anyway, if gdk or cairo itself as a 2d drawing library to implement
>> guis is not acceptable, there are others. Personally I would prefer
>> emacs to do gui in Lisp, not in C, so that C core could be simplifed
>> to just deal with OS windows, fonts and input, but as I understand
>> from the discussion, it is not acceptable.
>
> I can speak for Haiku at least when I say that Cairo isn't very
> portable.  On every not-that-popular platform (such as Haiku), you can
> only use image surfaces, and then you have to work out how to integrate
> them well with the toolkit provided by that platform, and things start
> to go downhill from there.

Ok, I understand.

> Besides, it will bring us no benefit at all, except to cause annoyance
> to many users.  (Have you ever tried making Fontconfig work properly on
> other platforms?  Cairo needs that for fonts.)  Most of the mess we have
> results from having to take care of the idiosyncrasies of each window
> system, and not implementing the basic drawing operations for that
> window system.

So you are lobbying for implementing Emacs own graphic context abstraction? :)

In general I think Emacs already has the code needed, but refactoring it is
probably quite a work. But it can be done :).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]