From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: embedding Mozilla in GNU Emacs via GTK? Date: Sat, 05 Mar 2005 15:01:06 +0100 Message-ID: References: <4n8y53i2w0.fsf@lifelogs.com> <01c52173$Blat.v2.4$fcf99d60@zahav.net.il> <87af1b80368c6430d466cab2836cc072@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110031174 30605 80.91.229.2 (5 Mar 2005 13:59:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 5 Mar 2005 13:59:34 +0000 (UTC) Cc: Ted Zlatanov , Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 05 14:59:33 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D7ZoK-0001hD-JL for ged-emacs-devel@m.gmane.org; Sat, 05 Mar 2005 14:59:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D7a7h-0006Eu-J1 for ged-emacs-devel@m.gmane.org; Sat, 05 Mar 2005 09:19:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D7a6h-0005vf-G8 for emacs-devel@gnu.org; Sat, 05 Mar 2005 09:18:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D7a6f-0005uR-7q for emacs-devel@gnu.org; Sat, 05 Mar 2005 09:18:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D7a6e-0005tF-R1 for emacs-devel@gnu.org; Sat, 05 Mar 2005 09:18:12 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D7ZqD-0002Pl-Gh for emacs-devel@gnu.org; Sat, 05 Mar 2005 09:01:22 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D7Zq8-0000BP-CI; Sat, 05 Mar 2005 09:01:08 -0500 Original-To: "Jan D." In-Reply-To: <87af1b80368c6430d466cab2836cc072@swipnet.se> (Jan D.'s message of "Sat, 5 Mar 2005 13:44:21 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:34216 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34216 "Jan D." writes: >>> From: Ted Zlatanov >>> Date: Fri, 04 Mar 2005 15:15:27 -0500 >>> >>> I am curious if there's a chance GNU Emacs will ever have an embedded >>> web browser object through the Mozilla GTK support: >> >> IIRC, this has come up before. If memory serves, the main problem was >> how to reconcile the Mozilla/GTK display functions with Emacs display >> engine principle of operation. Perhaps the situation has changed >> since then, though. > > I don't know the details about the display engine. I imagine that > is no problem as long as the GTK event loop is run properly. > Mozilla should handle its redisplay by function callbacks for expose > events and the like. But as long Emacs runs the X (or rather GTK) > event handling in a signal handler, this will be hard to make work > correctly, because the mozilla code may do just about anything. It > is possible it will work for most cases though. Before we do any such inclusion, we need to do a sane image support. For example, PNG provides functions to provide RGB information in 24bit or 32bit format, one color per pixel, with gamma correction applied using efficient lookup routines, in several byte orders. Now suppose that we have a true color visual displaying exactly that (practically all displays can support this sort of image type). What happens? PNG converts the image without getting the screen-gamma informationinto 16bit per pixel format. Then a look goes over all pixels and calls _two_ nested functions to convert _every_ _single_ pixel. If a gamma correction is to be applied, "pow" is called _three_ times per pixel. This is plainly insane. Our per-display data structures need to get a list of visuals (probably picking through the visuals until an optimal set for image operations has been gathered), and then the image reading routines (in particular where the png and jpeg libraries offer this functionality) need to get told the gamma correction factor, and then they read the stuff in in the _correct_ format and pass it directly to the X server. Scrolling through an image-infested buffer is still quite slow at the moment, and particularly so if gamma correction gets applied. This is entirely uncalled for. We _need_ to get this straightened out _completely_ before even _thinking_ of embedding any content that can change dynamically. The data structures need to go into the per-visual information, and the library must be allowed to generate 32-bit RGB _directly_ where the display permits this, instead of 48-bit RGB which then slowly gets converted one pixel at a time. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum