emacs-devel
[Top][All Lists]
Advanced

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

Re: GTK scroll bar question


From: Dmitry Antipov
Subject: Re: GTK scroll bar question
Date: Thu, 31 Jul 2014 19:13:53 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 07/31/2014 03:53 PM, Jan Djärv wrote:

We want to get rid of those as they are a performance hit.

Less widgets is not necessary means more performance.

The first Gtk+ version I made did not use handle_one_xevent, but it was
decided that the code in handle_one_xevent should be reused.  So it is
a no-brainer to replace it, it is just a lot of work.

The reason is that we have a lot of code in other places to handle timers
and other things (the whole xg_select.c file for example) that only comes
from not running the Gtk+ event loop.

It just confirms that Emacs is not a first-class Gtk+ citizen and will always
have OS- and so window system-specific code.

It is true that Cairo don't use pixmaps

What do you mean about "don't use"?

* xlib: Uses the Xlib interface to the X Window System. This backend can target
  Windows or Pixmaps. The Render extension is used if available, but is not 
required.

(http://cairographics.org/backends).

In particular, this will require
new redisplay interface to replace x_redisplay_interface

No it will not.

Get your favorite function from x_redisplay_interface and try to redesign
it by using only Gtk+ and Cairo interfaces.  Do not assume that Gtk+ is
backed by X, so no way to access underlying Display, Window, GC, etc.
I'm pretty sure you eventually finish with gtkterm.c :-).

From what was contained in the Gtk+ port only, you now distribute to three 
files,
and enlarge a struct for no good reason.  That is not elegant IMHO.

Pointers to Gtk+ widgets are OK in x_output, which is actually a part of frame.
So I don't see why it's so bad for scroll bars, especially if it's going to
replace _larger_ data structure with non-zero maintenance cost.

With all possible respect, we can't direct each other to do or not to do
something.  And we shouldn't, isn't it?


So when you can checkin to the Emacs tree, you feel you are in your right to
break code and generally change it so that the people that try to maintain
it can't recognize anymore?

Please re-read above. I mean "do", which is not always the same as "checkin".

Dmitry





reply via email to

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