From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dov Grobgeld Newsgroups: gmane.emacs.devel Subject: Re: Emacs as browser (was Re: Concurrency, again) Date: Sun, 23 Oct 2016 12:39:46 +0300 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <83mvi9a3mh.fsf@gnu.org> <20161012165911.58437154@jabberwock.cb.piermont.com> <20161012173314.799d1dc5@jabberwock.cb.piermont.com> <8360owaj2s.fsf@gnu.org> <20161013092701.77461800@jabberwock.cb.piermont.com> <20161017105345.2f255760@jabberwock.cb.piermont.com> <83y41nx8l6.fsf@gnu.org> <20161017123459.5ded9408@jabberwock.cb.piermont.com> <87vawosoul.fsf@elephly.net> <20161019090741.46ea2704@jabberwock.cb.piermont.com> <20161019163806.7c77f100@jabberwock.cb.piermont.com> <83twc7tqxr.fsf@gnu.org> <20161020111527.26bf4ab9@jabberwock.cb.piermont.com> <83h987t4c0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0c88c8532e58053f850e32 X-Trace: blaine.gmane.org 1477215612 7125 195.159.176.226 (23 Oct 2016 09:40:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Oct 2016 09:40:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 23 11:40:08 2016 Return-path: 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 ) id 1byFG1-0000I4-OP for ged-emacs-devel@m.gmane.org; Sun, 23 Oct 2016 11:39:57 +0200 Original-Received: from localhost ([::1]:40332 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byFG4-0006lk-3B for ged-emacs-devel@m.gmane.org; Sun, 23 Oct 2016 05:40:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byFFu-0006kT-B2 for emacs-devel@gnu.org; Sun, 23 Oct 2016 05:39:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byFFt-0007yn-65 for emacs-devel@gnu.org; Sun, 23 Oct 2016 05:39:50 -0400 Original-Received: from mail-lf0-x233.google.com ([2a00:1450:4010:c07::233]:33552) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byFFs-0007yI-PR for emacs-devel@gnu.org; Sun, 23 Oct 2016 05:39:49 -0400 Original-Received: by mail-lf0-x233.google.com with SMTP id x79so182735098lff.0 for ; Sun, 23 Oct 2016 02:39:48 -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=Cfp6jQlkOrsy7+Ps0wqy0xB9NX8jFE5uiAyVSdD8Gkc=; b=VZr/kGpfH7SvYKieNljlgdlIOyoAp81FHi+ccSDuremkQ5ZcAQOLeV5cpU9Ls8JEFj fu0j+LxOyZm3ig3Y8dcGCGIF7RpgoNvJahQijv0FO9MH49V3vWMhuwqglzfuZ2d1hw+O z9V4ELPK7pYfprvDi9cak7Lne9q6+SSf+TkHRDXDLILboRFUW0xBCCbtbW5oHQ36sSRA QOufaUWJheDZ8AuuN1M3Ta0AJ3dh9oE/wBbMUqaGMDE1midzmtZYqtpLL+YuTqQ5JjsZ nO1IBrcAPT9ItYwux2uPjJqiBu/sVGUAA2c+LvTd5JSNhb+payld2OV80E9p1tZSQR1z ioHw== 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=Cfp6jQlkOrsy7+Ps0wqy0xB9NX8jFE5uiAyVSdD8Gkc=; b=e1WvD0JJufn4HvbUIuJtU3mLKGHwOWCQIvWMAGk1M0NQJLLj+49AtKoLcypvmxvrbD Tt2Pkly6R7Qd9gcks1JVNxJt1vLlcboP4jWDvwMa2aTcn3jEqjmWVyMf65sqzHTYycxy SR/QwCK197SuAjdlMWzojzeCoNqTMqay1httg87SgpB9r3pFECXLGI3gnrjlo6OwnV7T sf+f6486OLjfoOEJMjiJRfurhWCVbNlQslq+QxQnl4gvtciO9TGTYjwZDFzHSHk/p19e cd4tN3UGFLfQ32jlmfDCkSKFjRurlEvM/9OV/y4v0zIZdhB9YpLvj0y/VRhepVBLLaoU wj8g== X-Gm-Message-State: ABUngvdOF8Ue6K5KtUx28LYgLF0YZsDOPYCamofThEeS18k11GXxtWjMuQt0W27GtR0ABLzrXnC3Pj4gYNBQgQ== X-Received: by 10.25.92.203 with SMTP id u72mr4282354lfi.62.1477215587083; Sun, 23 Oct 2016 02:39:47 -0700 (PDT) Original-Received: by 10.25.99.14 with HTTP; Sun, 23 Oct 2016 02:39:46 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208613 Archived-At: --94eb2c0c88c8532e58053f850e32 Content-Type: text/plain; charset=UTF-8 I had a look at the image magick bug and I'm afraid that I don't understand what is going on, but it seems like it has nothing to do with cairo. This is what I have found. - The ImageMagick image is loaded in image.c:image_create_x_image_and_pixmap() which causes XCreateImage() to be called. The image is then populated in imagemagick_load_image() through calls to XPutPixel() with data from the imagemagick image. - The image is then displayed through a call to XCopyArea() in xterm.c , but instead of showing the original image, garbage (copies of various rectangles pieces of the display) is shown instead. My guess is that either something went wrong with the creation of the ximg or it was released before XCopyArea() was called. I'd be happy to hear if someone has any idea of what is going on and how to debug this. (Btw, how do you print a Lisp_Object in gdb? Probably a FAQ...) Regards, Dov On Sun, Oct 23, 2016 at 9:23 AM, Dov Grobgeld wrote: > 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 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.) >> >> > --94eb2c0c88c8532e58053f850e32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had a look at the image magick bug and I'm afraid= that I don't understand what is going on, but it seems like it has not= hing to do with cairo.

This is what I have found.
    The ImageMagick image is loaded in image.c:image_create_x_image_and_pixma= p() which causes XCreateImage() to be called. The image is then populated i= n imagemagick_load_image() through calls to XPutPixel() with data from the = imagemagick image.
  • The image is then displayed through a call to XC= opyArea() in xterm.c , but instead of showing the original image, garbage (= copies of various rectangles pieces of the display) is shown instead.
    • <= /ul>

    My guess is that either something went wrong with the creation of th= e ximg or it was released before XCopyArea() was called.

    I'd be h= appy to hear if someone has any idea of what is going on and how to debug t= his.

    (Btw, how do you print a Lisp_Object in gdb? Probably a FAQ...)<= /p>

    Regards,

    Dov



On Sun, Oct 23, 2016 at 9:23 AM, Dov = Grobgeld <dov.grobgeld@gmail.com> wrote:
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 leve= l 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 are= a, 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 n= or 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 &= quot;cairo expert" 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.

 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 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.)



--94eb2c0c88c8532e58053f850e32--