1. 09 Feb, 2016 1 commit
  2. 08 Feb, 2016 7 commits
  3. 07 Feb, 2016 16 commits
  4. 06 Feb, 2016 15 commits
    • Piotr Drąg's avatar
      Updated Polish translation · 1a524f37
      Piotr Drąg authored
      1a524f37
    • Matthias Clasen's avatar
      level bar: Fix offset behavior · ccd8c76f
      Matthias Clasen authored
      We had some odd special-casing for the lowest and highest offset
      that did not quite work. The new rule is simple: If the value
      is between offset n-1 and n, it gets the style for offset n.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761416
      ccd8c76f
    • Matthias Clasen's avatar
      level bar: Improve documentation · 1a71579b
      Matthias Clasen authored
      The docs were not explaining at all what happens to existing
      level offsets when the min- or max-value of a level bar are
      changed.
      1a71579b
    • Matthias Clasen's avatar
      level bar: Make the full offset official · 8776bb53
      Matthias Clasen authored
      We are adding 3 offsets, not just two. Add a define for the
      third one, and mention it in the docs.
      8776bb53
    • Dušan Kazik's avatar
      Updated Slovak translation · 7b668660
      Dušan Kazik authored
      7b668660
    • Ray Strode's avatar
      wayland: rework buffer management code (3 changes) · 2ebae407
      Ray Strode authored
      There are a couple of issues with the way that buffers are handled in
      wayland in right.  These issues mean that:
      
       - buffers can get leaked at a fairly fast clip under the right
         conditions. This leads to the OOM killer kicking in and
         gnome-shell and gnome-terminal (for instance) showing memory
         usage in the high gigabytes range.
      
       - drawing can happen to a shared memory buffer at the same time
         the compositor is reading out the pixels.  This can lead to
         glitching in drawing and other undefined behavior by the compositor.
      
      This changeset reworks how buffer management is done in the code to try
      to address both problems.
      
      The first change (commit 2c300081) addresses the leak by dropping code
      that has an unchecked cairo_surface_reference call.  The code is dropped
      rather than fixed, because it has a more serious issue: it's overarching
      purpose is to deal with shared memory buffer contention with the
      compositor, but it does it in a racy way and so fails at that mission.
      
      The second change (commit 40e91195) moves what layer of the code buffer
      release events are handled. This is an organizational change in the
      code, with no functional changes, but it's important for the last change
      in the changeset.
      
      The last change (commit c80dd549) adds back code for dealing with shared
      member buffer contention in a race free way. The new code is careful to
      never reuse a buffer that hasn't been explicitly released by the
      compositor.
      2ebae407
    • Ray Strode's avatar
      wayland: stage uncommitted changes to dedicated buffer · c80dd549
      Ray Strode authored
      Right now we use one buffer for both staged changes (freshly painted
      changes waiting for the frame clock to send to the compositor) and
      committed changes (changes actively being read by the compositor
      process). This creates a problem in the event we need to stage updates
      at the same time the compositor is processing committed updates: we
      can't change what the compositor is actively processing.
      
      The current solution for handling this contention is to allocate a
      temporary buffer on the spot at the time the updates are staged, and to
      copy that buffer back to the shared buffer later.  The problem, though,
      is that the copy to the shared buffer currently happens as soon as
      the updates are finished being staged, not when the shared buffer is
      done being processed by the compositor.
      
      In order to address that problem, this commit changes the code to always
      stage changes to a dedicated staging buffer.  The staging buffer is
      used exclusively by the client until the client is done with it, and then
      once that staging buffer is committed, the client never writes to that
      buffer again.  If the client needs to stage new updates, it allocates a
      brand new staging buffer, draws to it, and back fills the undrawn parts
      of the buffer from a copy of the contents of the committed buffer.
      
      As an optimization, the compositor has the option of releasing the
      committed buffer back to the client.  If it does so before the client
      needs to stage new updates, then the client will reuse the buffer
      for staging future updates.  This optimization prevents having to allocate
      a new staging buffer and the associated cost of back filling
      that new buffer with a readback of the committed buffer.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      c80dd549
    • Ray Strode's avatar
      wayland: don't handle buffer release centrally · 40e91195
      Ray Strode authored
      Right now we handle buffer releases coming from the
      compositor in a central place. We add a listener when
      first creating the shared buffers.
      
      This is problematic because a buffer can only have
      one listener on it at once so users of the buffer
      can't get notified when it's released.
      
      This commit moves the buffer listener code from the
      centrally managed display code to the cursor and window
      code.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      40e91195
    • Ray Strode's avatar
      wayland: always return FALSE from begin_paint · 2c300081
      Ray Strode authored
      The client and compositor share access to the window
      pixel buffers. After the client hands off (commits)
      the buffer to the compositor it's not supposed to write
      to it again until it's released by the compositor.
      
      The code tries to deal with this contention by allocating
      a temporary buffer and using that in the mean time. This
      temporary buffer is allocated by a higher layer of the code
      when begin_paint returns TRUE. Unfortunately, that layer of
      the code has no idea when the buffer is released, so it ends
      up blitting the temporary buffer back to the shared buffer
      prematurely.
      
      This commit changes begin_paint to always return FALSE.
      
      A future commit will address the contention problem in
      a different way.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      2c300081
    • Ray Strode's avatar
      wayland: use g_clear_pointer when destroying cairo surfaces · 1cfa2f41
      Ray Strode authored
      There are a few places where we destroy a cairo surface and
      then nullify it. This commit changes those to use
      g_clear_pointer instead.
      
      It also drops a cairo_surface_finish call that is unnecessary
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      1cfa2f41
    • Ray Strode's avatar
      wayland: rename cairo surface user data key to be more specific · e6f92df5
      Ray Strode authored
      This commit renames the key name to be more specific for clarity.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      e6f92df5
    • Ray Strode's avatar
      wayland: move server proxy objects to substructure · 3ac78ea0
      Ray Strode authored
      This commit moves the server proxy objects to a substructure
      for clarity.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      3ac78ea0
    • Ray Strode's avatar
      wayland: rename window->surface to window->wl_surface · f90db30b
      Ray Strode authored
      The name surface is really overloaded when dealing
      with wayland windows.
      
      To alleviate ambiguity, this commit changes the name
      of the "surface" and "subsurface" members to have
      a wl_ prefix.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=761312
      f90db30b
    • Matthias Clasen's avatar
      Fix stylecontext tests · 4d40bd44
      Matthias Clasen authored
      This was broken by f7ec9c98,
      since type names are no longer used at all in CSS matching.
      4d40bd44
    • Matthias Clasen's avatar
      Update CSS docs regarding type names · 2d1f1f3b
      Matthias Clasen authored
      We no longer use type names at all.
      2d1f1f3b
  5. 05 Feb, 2016 1 commit