<div dir="ltr"><div>Hi,</div><div><br></div><div>(Re-adding xorg-devel. Please make sure to keep the list CC'd in the future)<br></div><div><br></div><div>It is possible for a window to set "no background color", in which case the existing window contents are used for the pixmap. xclock likely sets no background color. You can check an individual window's properties with xwininfo.</div><div><br></div><div>Redrawing the screen every frame isn't a bad idea for a simple compositor to get started. For a more fancy, complete redraw loop, you can track when windows get drawn to with with the Damage extension, and schedule a repaint when that happens. Bonus points if you use the damage rectangles to be more accurate with your redraw. Also, helpful hint that windows get their backing pixmaps thrown away when resized -- you need to pay attention to ConfigureNotify and regrab the backing pixmap with XCompositeNameWindowPixmap, and that whole jazz.<br></div><div><br></div><div>I don't recommend synthesizing input events -- a lot of things are likely to break or just not work well. Set an empty input shape on the COW, and make sure to draw windows where they want to be. Pay attention to MotionNotify events from windows that are moving.</div><div><br></div><div>I'm unaware of any beginner-level documentation or tutorials. The number of people that have written a compositing manager from scratch can be counted on one hand, and a lot of them had a hand in designing the architecture to begin with. <a href="https://magcius.github.io/xplain/article/composite.html">https://magcius.github.io/xplain/article/composite.html</a> has some ideas of the broader concepts, but none of the details.<br></div><div><br></div><div>Good luck. <br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 2:01 AM Egil Möller <<a href="mailto:egil@innovationgarage.no" target="_blank">egil@innovationgarage.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_-2101153908760320254m_6207735482299778215m_-7306930591589895831moz-cite-prefix">Hi!<br>
      <br>
      Thanks for answering a noob question :) Ha! That's so not
      documented (in an obvious way)! I was assuming that I could get
      the initial window content, as already drawn (obviously clipped to
      whatever is visible on screen) directly... So why does xclock
      "work" then? I just haven't gotten around to event handling yet,
      wanted to learn the drawing/copying methods themselves first...<br>
      <br>
      Two follow up questions:<br>
      <br>
        * How should I redraw the screen? As often as I can, or waiting
      for some event for all redirected windows (which event)?<br>
        * Can I capture input events (key, mouse) for the overlay window
      and then somehow synthesize them for whatever window / subwindow
      my window manager thinks it has drawn in that position? Some docs
      I read sounded like this is impossible, and you should turn of
      input for the overlay, and position the real window underneath in
      a "strategic position"...<br>
      <br>
      Also, is there any good documentation and/or tutorials around this
      anywhere?<br>
      <br>
      /Egil<br>
      <br>
      On 19. juni 2018 08:42, Jasper St. Pierre wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Hi,</div>
        <div><br>
        </div>
        <div>What you're seeing here is a fun little side effect of
          composite. As you might be aware, unredirected X windows don't
          have any backing storage beyond the front buffer -- the full
          window contents are not really there. That means that when the
          X server first goes to redirect these windows, it decides that
          it should let the window paint again, and sends the window an
          Expose event to let it know it should repaint. A side effect
          of this is that the X server redraws the background for the
          window. This is the semantics for what an Expose event means
          -- an area that is "Exposed" is the background color until the
          client paints over it.</div>
        <div><br>
        </div>
        <div>The client will eventually paint its window contents, but
          since your CM does not appear to have a frame loop, and it
          only paints once, you do not see the updated frame contents.<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Sun, Jun 17, 2018 at 1:28 PM Egil Möller <<a href="mailto:egil@innovationgarage.no" target="_blank">egil@innovationgarage.no</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
          <br>
          I'm trying to write a new compositing window manager, and
          finding the<br>
          documentation for the API:s I need quite spread out.<br>
          <br>
          The particular problem I'm having right now is that copying
          some windows (xclock) using<br>
          XCompositeRedirectSubwindows and e.g. XRenderComposite works
          fine, while<br>
          other windows (xterm, xlock) leaves me we a square with only
          their<br>
          background color. This seems to be true for both
          XRenderComposite and <br>
          glXBindTexImageEXT. Any ideas what's different between them,
          and what I<br>
          need to do differently?<br>
          <br>
          My code is here: <a href="https://github.com/redhog/InfiniteGlass" rel="noreferrer" target="_blank">https://github.com/redhog/InfiniteGlass</a><br>
          (main code is in wm.c; running "make" ahould give you an
          Xephyr nested X<br>
          session that shows the problem).<br>
          <br>
          Thanks in advance,<br>
          <br>
          Egil Möller<br>
          <br>
          <br>
          <br>
          _______________________________________________<br>
          <a href="mailto:xorg-devel@lists.x.org" target="_blank">xorg-devel@lists.x.org</a>: X.Org
          development<br>
          Archives: <a href="http://lists.x.org/archives/xorg-devel" rel="noreferrer" target="_blank">http://lists.x.org/archives/xorg-devel</a><br>
          Info: <a href="https://lists.x.org/mailman/listinfo/xorg-devel" rel="noreferrer" target="_blank">https://lists.x.org/mailman/listinfo/xorg-devel</a></blockquote>
      </div>
      <br clear="all">
      <br>
      -- <br>
      <div dir="ltr" class="m_-2101153908760320254m_6207735482299778215m_-7306930591589895831gmail_signature" data-smartmail="gmail_signature">  Jasper<br>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div>

</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-2101153908760320254m_6207735482299778215gmail_signature" data-smartmail="gmail_signature">  Jasper<br></div></div>