Re: embedding Mozilla in GNU Emacs via GTK?

[David Kastrup]

"Jan D." <address@hidden> writes:

>>> From: Ted Zlatanov <address@hidden>
>>> 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