1. 26 Apr, 2019 1 commit
  2. 27 Apr, 2019 2 commits
    • violet's avatar
      Bug 1547209 - Compute transform matrix directly in... · 17083b6e
      violet authored
      Bug 1547209 - Compute transform matrix directly in nsSVGUtils::GetTransformMatrixInUserSpace r=longsonr
      
      Since now most CSS transform related bugs are fixed, it's clear that the
      purpose of nsSVGUtils::GetTransformMatrixInUserSpace() should solely be to
      replace SVGElement::PrependLocalTransformsTo(eUserSpaceToParent).
      
      After fixing Bug 972041, the only other usecase (Bug 1247218) no longer exists.
      
      OTOH, there is a problem when the parent has a viewbox transform, in that case,
      SVGElement::PrependLocalTransformsTo() doesn't include it, but
      nsLayoutUtils::GetTransformToAncestor() does.
      
      In fact, it's much easier to compute the transform matrix directly based on
      the implementation of nsDisplayTransform::GetResultingTransformMatrixInternal(),
      which is also the function internally called by nsLayoutUtils::GetTransformToAncestor().
      
      In particular, we don't need to look at 3D stuff since our matrix is inherently 2D.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28970
      
      --HG--
      extra : moz-landing-system : lando
      17083b6e
    • violet's avatar
      Bug 972041 - getCTM should account for CSS transform r=longsonr · 92d63fc9
      violet authored
      We use nsSVGUtils::GetTransformMatrixInUserSpace to support
      CSS transform in getCTM.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28969
      
      --HG--
      extra : moz-landing-system : lando
      92d63fc9
  3. 26 Apr, 2019 1 commit
  4. 27 Apr, 2019 2 commits
  5. 26 Apr, 2019 1 commit
    • Alastor Wu's avatar
      Bug 1540748 - part2 : add warning for negative adjusted time. r=jolin · 31a6a91d
      Alastor Wu authored
      As the purpose of adjusting time is to make the start of the playback to align to zero, so the result should not be negative.
      
      However, we can't always ensure the demuxed start time is correct, the decoded first frame sample time might be different with the time demuxer provides.
      
      Even if we try to update the start time when we get the first decoded sample, there is still a problem because a decoder might return samples with different order, which means the first frame the decoder returns is probably not a real first frame.
      
      Therefore, using warning to help us knows how many this situaion would be.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28432
      
      --HG--
      extra : moz-landing-system : lando
      31a6a91d
  6. 25 Apr, 2019 1 commit
    • Alastor Wu's avatar
      Bug 1540748 - part1 : Android decoder should throw an error when the decoded... · 285ab3ee
      Alastor Wu authored
      Bug 1540748 - part1 : Android decoder should throw an error when the decoded sample's time is smaller than the time of first demuxed sample. r=jolin
      
      Considering that the audio sample's time is always increased, the decoded sample's time decoder returns should always be equal or larger than its demuxed time.
      
      When the decoded sample's time is smaller than the time of first demuxed sample, that time would probably cause a problem so we should  throw an error for that.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28167
      
      --HG--
      extra : moz-landing-system : lando
      285ab3ee
  7. 27 Apr, 2019 12 commits
  8. 26 Apr, 2019 20 commits