From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED!not-for-mail
From: Dov Grobgeld <dov.grobgeld@gmail.com>
Newsgroups: gmane.emacs.devel
Subject: Re: Emacs as browser (was Re: Concurrency, again)
Date: Sun, 23 Oct 2016 09:23:51 +0300
Message-ID: <CA++fsGGD-CVCwGaf2KFG-fNvS=hbwVS2-T0mixewoEZ=+L+rrQ@mail.gmail.com>
References: <87wq97i78i.fsf@earlgrey.lan> <83mvi9a3mh.fsf@gnu.org>
	<m2h98h8n0g.fsf@newartisans.com>
	<jwvfuo1v047.fsf-monnier+emacs@gnu.org>
	<20161012165911.58437154@jabberwock.cb.piermont.com>
	<CAGXii2aZdC57gdpzSF3n_AxscDSuURcYmD30yg6bTM=gAa5bRA@mail.gmail.com>
	<20161012173314.799d1dc5@jabberwock.cb.piermont.com>
	<8360owaj2s.fsf@gnu.org>
	<20161013092701.77461800@jabberwock.cb.piermont.com>
	<jwvk2dcmgwb.fsf-monnier+gmane.emacs.devel@gnu.org>
	<m2fuo0kvp5.fsf@newartisans.com>
	<20161017105345.2f255760@jabberwock.cb.piermont.com>
	<83y41nx8l6.fsf@gnu.org>
	<20161017123459.5ded9408@jabberwock.cb.piermont.com>
	<E1bwaMR-00084d-CE@fencepost.gnu.org> <87vawosoul.fsf@elephly.net>
	<20161019090741.46ea2704@jabberwock.cb.piermont.com>
	<E1bwx49-0006Sv-QK@fencepost.gnu.org>
	<20161019163806.7c77f100@jabberwock.cb.piermont.com>
	<83twc7tqxr.fsf@gnu.org>
	<20161020111527.26bf4ab9@jabberwock.cb.piermont.com>
	<83h987t4c0.fsf@gnu.org>
	<CA++fsGHuYmi+GhA=Wuvs5hnceWX+ptJQOz99LA+nhkqrvXKCsw@mail.gmail.com>
	<ae73bbca-a096-123b-dc9f-c496ea8479a9@cs.ucla.edu>
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a113fc314b87ca5053f825163
X-Trace: blaine.gmane.org 1477203862 15022 195.159.176.226 (23 Oct 2016 06:24:22 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Sun, 23 Oct 2016 06:24:22 +0000 (UTC)
Cc: emacs-devel@gnu.org
To: Paul Eggert <eggert@cs.ucla.edu>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 23 08:24:18 2016
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1byCCQ-00015Y-7W
	for ged-emacs-devel@m.gmane.org; Sun, 23 Oct 2016 08:24:02 +0200
Original-Received: from localhost ([::1]:39842 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1byCCR-0004Bj-Ai
	for ged-emacs-devel@m.gmane.org; Sun, 23 Oct 2016 02:24:03 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48838)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dov.grobgeld@gmail.com>) id 1byCCL-0004BP-87
	for emacs-devel@gnu.org; Sun, 23 Oct 2016 02:23:58 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dov.grobgeld@gmail.com>) id 1byCCK-0001D1-B8
	for emacs-devel@gnu.org; Sun, 23 Oct 2016 02:23:57 -0400
Original-Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:35303)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <dov.grobgeld@gmail.com>)
	id 1byCCK-00019A-1x
	for emacs-devel@gnu.org; Sun, 23 Oct 2016 02:23:56 -0400
Original-Received: by mail-lf0-x232.google.com with SMTP id f134so9366143lfg.2
	for <emacs-devel@gnu.org>; Sat, 22 Oct 2016 23:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=o4lOW01kEulrMFOjQNBDcwD9PM/1Dhwxudz7z4vAHJ0=;
	b=m1SGyDqlg8pxvNJTGgIrWEmR0NPdDL4uI3d4qxT6AGjHoDKkJtPtWS6xFlAoTHLbK4
	jIXCYpflDjbRKjQB+n+9t3VNCKrb95BfYASuV8Dwr4a59QmNoHGSD2idM+dwbCLobcKP
	3J9pPRV4Yw7eXTkQfaOt12Gkmb+psnrOhnTYK9C0tgcTC2QoNFKhRWT+1eRXmLiVHqsX
	Uv8Cgdi/asSskwIomH9dwxKgF67QSJjaXbVLIsdx/clr7rKcU2IGFYrNDmHWLjV33dpN
	3l+lDxc+d/0q4Ywa089eUqBovacn4/DXHmIi2dZbgQqbmVSKf+CnW+c+AUg4F5dgjneH
	pPag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=o4lOW01kEulrMFOjQNBDcwD9PM/1Dhwxudz7z4vAHJ0=;
	b=WCqY8/SBf/aPJeCaSyAoQ3gen8I+3h9lvuoMZzsDgY/kh5fvXiV6SBXzL6Wpu5S0Ia
	mN4XLq0IiR1ea3/GDkAHrVjM37ALJ8vYGpkaKcjSTyf/3ROkUn/JXajHcw2x/M/Effqq
	4RGvCyS8pUvCNGmIBgcDwmaqB/dmV2IP6Y20z/229hELxSuRHQ+UFMGVP/UTLU1FSh5J
	SvjxkV2BKlebUMboutyIuXo+ZxzojCl+FV4rdCOnyWAkFh0pIF7gWMGRMv6lf7wmLNSV
	sNqrB1WWjekJ5/v/bDXZpVBtcEvU4PWaUtCHwDfSlIRRWKZd5raWYOfbIvFBigISKl4T
	lwBA==
X-Gm-Message-State: ABUngvf1swOReUUQDx43fBeY300OGrNXTn/gLKTZtec5SzTCIks9EX7GA8ezT6uUNxqXSaUuKNcdfKfKh39CJg==
X-Received: by 10.25.134.139 with SMTP id i133mr4039623lfd.27.1477203832895;
	Sat, 22 Oct 2016 23:23:52 -0700 (PDT)
Original-Received: by 10.25.99.14 with HTTP; Sat, 22 Oct 2016 23:23:51 -0700 (PDT)
In-Reply-To: <ae73bbca-a096-123b-dc9f-c496ea8479a9@cs.ucla.edu>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2a00:1450:4010:c07::232
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:208608
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/208608>

--001a113fc314b87ca5053f825163
Content-Type: text/plain; charset=UTF-8

Yes, 22691.

And I was indeed able to reproduce the png display bug with ImageMagick.
I'll try to look in to it.

And regarding cairo, from a top level view it is quite simple. It receives
a memory buffer and draws pixels in the buffer. The memory buffer may be
either a "normal" memory area, or together with gdk an GdkWindow. Its
painting model is PostScript (or svg) like, e.g. moveto, lineto, curveto,
stroke, fill, and draw glyphs. It is simpler than than the X11 drawing
model as there are e.g. no XOR modes nor 8-bit index modes, etc. The rest
is details. :-)

Regards,
Dov



On Fri, Oct 21, 2016 at 10:43 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 10/21/2016 12:31 AM, Dov Grobgeld wrote:
>
>> My feeling is that the only issue in the bug tracker that you may need an
>> "cairo expert" for, is the memory leak in #22961. The rest of the bugs are
>> more related to exposure triggered redraws and interaction with the window
>> manager. These are certainly related to the cairo branch, but have nothing
>> to do with cairo per se.
>>
>
> I assume you meant Bug#22691, not Bug#22961.
>
> Did you build the origin/old-branches/cairo branch with ImageMagick as
> well? The master-branch Cairo problems I ran into involved interaction with
> ImageMagick (Bug#21110, Bug#22442). Or is that interaction also a refresh
> issue? (Please bear with me, as I know little about Cairo.)
>
>

--001a113fc314b87ca5053f825163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Yes, 22691. <br><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif">And I was indeed able to r=
eproduce the png display bug with ImageMagick. I&#39;ll try to look in to i=
t.<br><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif">And regarding cairo, from a top level view it is quite s=
imple. It receives a memory buffer and draws pixels in the buffer. The memo=
ry buffer may be either a &quot;normal&quot; memory area, or together with =
gdk an GdkWindow. Its painting model is PostScript (or svg) like, e.g. move=
to, lineto, curveto, stroke, fill, and draw glyphs. It is simpler than than=
 the X11 drawing model as there are e.g. no XOR modes nor 8-bit index modes=
, etc. The rest is details. :-)<br><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif">Regards,<br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">Dov<br=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif"><br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Fri, Oct 21, 2016 at 10:43 PM, Paul Eggert <span dir=3D"ltr=
">&lt;<a href=3D"mailto:eggert@cs.ucla.edu" target=3D"_blank">eggert@cs.ucl=
a.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 10/21/2016 12:31 AM, Dov Grobgeld wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My feeling is that the only issue in the bug tracker that you may need an &=
quot;cairo expert&quot; for, is the memory leak in #22961. The rest of the =
bugs are more related to exposure triggered redraws and interaction with th=
e window manager. These are certainly related to the cairo branch, but have=
 nothing to do with cairo per se.<br>
</blockquote>
<br></span>
I assume you meant Bug#22691, not Bug#22961.<br>
<br>
Did you build the origin/old-branches/cairo branch with ImageMagick as well=
? The master-branch Cairo problems I ran into involved interaction with Ima=
geMagick (Bug#21110, Bug#22442). Or is that interaction also a refresh issu=
e? (Please bear with me, as I know little about Cairo.)<br>
<br>
</blockquote></div><br></div>

--001a113fc314b87ca5053f825163--