1. 22 May, 2019 3 commits
  2. 21 May, 2019 19 commits
  3. 20 May, 2019 2 commits
    • Florian Müllner's avatar
      ci: Update Dockerfile to :v2 · 9c2fdcdb
      Florian Müllner authored
      This commit is a bit deceitful: The main change in the image is *not* the
      more recent Fedora base, but an updated (and not backward-compatible)
      evolution-data-server package from the fmuellner/gnome-shell-ci copr.
      
      gnome-shell!501 ports
      gnome-shell to the new API, so to keep mutter and gnome-shell CI
      working after that change, we need to build against the correct
      EDS version.
      
      !582
      9c2fdcdb
    • Florian Müllner's avatar
      ci: Disable a11y bus for tests · d4a0893d
      Florian Müllner authored
      While the regular session bus is provided by `dbus-run-session`, the
      a11y bus is spawn by the "normal" D-Bus daemon (that is, dbus-broker
      in F30). This currently fails, either due to a bug or some missing
      dependencies in the container environment. But as we don't actually
      need the additional bus, just disable it via the environment to make
      not break tests when updating the base image to F30.
      
      !582
      d4a0893d
  4. 17 May, 2019 1 commit
  5. 16 May, 2019 3 commits
    • Daniel van Vugt's avatar
      clutter/stage-cogl: Don't skip over the next frame · 45244852
      Daniel van Vugt authored
      The `last_presentation_time` is usually a little in the past (although
      sometimes in the future depending on the driver). When it's over 2ms
      (`sync_delay`) in the past that would trigger the while loop to count up so
      that the next `update_time` is in the future.
      
      The problem with that is for common values of `last_presentation_time`
      which are only a few milliseconds ago, incrementing `update_time` by
      `refresh_interval` also means counting past the next physical frame that
      we haven't rendered yet. And so mutter would skip that frame.
      
      **Example**
      
      Given:
      ```
        last_presentation_time = now - 3ms
        sync_delay = 2ms
        refresh_interval = 16ms
        next_presentation_time = last_presentation_time + refresh_interval
                               = now + 13ms
      
                -3ms now        +13ms           +29ms           +45ms
              ----|--+------------|---------------|---------------|----
                  :               :
        last_presentation_time  next_presentation_time
      ```
      
      Old algorithm:
      ```
        update_time = last_presentation_time + sync_delay
                    = now - 1ms
        while (update_time < now)
              (now - 1ms   < now)
          update_time = now - 1ms + 16ms
        update_time = now + 15ms
        next_presentation_time = now + 13ms
        available_render_time = next_presentation_time - max(now, update_time)
                              = (now + 13ms) - (now + 15ms)
                              = -2ms  so the next frame will be skipped.
      
                -3ms now        +13ms           +29ms           +45ms
              ----|--+------------|-+-------------|---------------|----
                  :               : :
                  :               : update_time (too late)
                  :               :
        last_presentation_time  next_presentation_time (a missed frame)
      
      ```
      
      New algorithm:
      ```
        min_render_time_allowed = refresh_interval / 2
                                = 8ms
        max_render_time_allowed = refresh_interval - sync_delay
                                = 14ms
        target_presentation_time = last_presentation_time + refresh_interval
                                 = now - 3ms + 16ms
                                 = now + 13ms
        while (target_presentation_time - min_render_time_allowed < now)
              (now + 13ms - 8ms < now)
              (5ms < 0ms)
          # loop is never entered
        update_time = target_presentation_time - max_render_time_allowed
                    = now + 13ms - 14ms
                    = now - 1ms
        next_presentation_time = now + 13ms
        available_render_time = next_presentation_time - max(now, update_time)
                              = (now + 13ms) - now
                              = 13ms  which is plenty of render time.
      
                -3ms now        +13ms           +29ms           +45ms
              ----|-++------------|---------------|---------------|----
                  : :             :
                  : update_time   :
                  :               :
        last_presentation_time  next_presentation_time
      ```
      
      The reason nobody noticed these missed frames very often was because
      mutter has some accidental workarounds built-in:
      
       * Prior to 3.32, the offending code was only reachable in Xorg sessions.
         It was never reached in Wayland sessions because it hadn't been
         implemented yet (till e9e4b2b7).
      
       * Even though Wayland support is now implemented the native backend
         provides a `last_presentation_time` much faster than Xorg sessions
         (being in the same process) and so is less likely to spuriously enter
         the while loop to miss a frame.
      
       * For Xorg sessions we are accidentally triple buffering (#334). This
         is a good way to avoid the missed frames, but is also an accident.
      
       * `sync_delay` is presently just high enough (2ms by coincidence is very
         close to common values of `now - last_presentation_time`) to push the
         `update_time` into the future in some cases, which avoids entering the
         while loop. This is why the same missed frames problem was also noticed
         when experimenting with `sync_delay = 0`.
      
      v2: adjust variable names and code style.
      
      Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=789186
             and most of #571
      
      !520
      45244852
    • Marco Trevisan's avatar
      gitlab-ci: Use MALLOC_CHECK_ and MALLOC_PERTURB_ env variables in tests · e96136e4
      Marco Trevisan authored
      Linux glibc supports a malloc implementation that is allows to be tunable using
      environment variables, to check allocation issues.
      
      When MALLOC_CHECK_ is set to 3, a diagnostic message is printed on stderr and
      the program is aborted.
      
      Setting the MALLOC_PERTURB_ environment variable causes the malloc functions in
      to return memory which has been wiped and initialized with the byte value of the
      environment variable.
      
      So use this features when running tests in order to catch better memory errors.
      
      !578
      e96136e4
    • Daniel Mustieles García's avatar
      Updated Spanish translation · eae6e7a8
      Daniel Mustieles García authored
      eae6e7a8
  6. 15 May, 2019 9 commits
  7. 14 May, 2019 3 commits