From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs, QT and Cairo Date: Wed, 14 Jul 2010 10:39:02 +0900 Message-ID: <87zkxuhmfd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4C3CD120.4040905@swipnet.se> <5A91499A-0470-43FD-9F48-560CEAD3424C@mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279071937 5162 80.91.229.12 (14 Jul 2010 01:45:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Jul 2010 01:45:37 +0000 (UTC) Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= , Emacs development discussions To: Chad Brown Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 14 03:45:36 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OYr2R-0007rH-TI for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 03:45:32 +0200 Original-Received: from localhost ([127.0.0.1]:53531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYr2R-0005PE-D8 for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 21:45:31 -0400 Original-Received: from [140.186.70.92] (port=59985 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYr2L-0005P6-0W for emacs-devel@gnu.org; Tue, 13 Jul 2010 21:45:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYr2J-0001Ri-J0 for emacs-devel@gnu.org; Tue, 13 Jul 2010 21:45:24 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:58566) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYr2J-0001RI-2X for emacs-devel@gnu.org; Tue, 13 Jul 2010 21:45:23 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0EBD61535AE; Wed, 14 Jul 2010 10:45:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E095B1A2691; Wed, 14 Jul 2010 10:39:02 +0900 (JST) In-Reply-To: <5A91499A-0470-43FD-9F48-560CEAD3424C@mit.edu> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127239 Archived-At: Chad Brown writes: > It would be interesting to see an analysis of emacs' redisplay > needs in light of modern cpu/gpu/network usage, or even a list of > needs for emacs' redisplay priorities. I recall the 18->19->20 > discussions vaguely, but I'm willing to wager that there are far > fewer people using x-terminals over 14.4k modem lines these days. > :-) Nowadays redisplay is all about memory and networks. Forget CPU and GPU. Client memory is probably not that important (unless you cache a lot of off-screen real estate), and even server memory shouldn't be a problem for Emacs, which makes fairly modest demands (except for glyph caching if you're using Xft). I regularly get complaints from people about redisplay over the network. The problem as usual is not bandwidth (what is measured by "14.4k"), but latency. It's the number of roundtrips that matters, and modern WANs often have greater average latency than a modem line. I'm typing this on a link that goes through 10 hosts with IPs to travel a net of 4.5km, and the performance is, if anything, worse than the 28.8k modem I used to use; on my sabbatical that was 15-20 hosts and 10,000km, so speed of light became a factor and it could be awful. Of course if you've got lots of toolbar icons and suchlike, it takes more time to upload them to the X server over a 14.4k line, but once they're uploaded, they generally hang around for a long time since server memory has expanded enormously. > A `truly excellent' effort in this space would almost certainly > require a huge amount of work from at least one of the already > generous/overburdened developers who truly understands the > redisplay internals, That's not clear (although my opinion may not be accurate since the XEmacs redisplay is quite different). For example, one of the tasks that has a very complicated implementation in the XEmacs redisplay is drawing the cursor. But that's because in the basic X protocol you need to draw things in layers. It's possible that in a Cairo implementation some of these things could call out to the RENDER protocol, which would allow full use of Porter-Duff. While that would indeed require somebody to book up on Porter-Duff and probably some ingenuity in figuring out how to use the 31 (IIRC) composition operators to achieve minimal roundtrips, this would be quite local, and not require overall redisplay complexity.