tree ad6f9b131c7446278e809787001e8c516976d944
parent 22bb52e95b92d15919450ab3a360355be287463e
author Mike Klein <mtklein@google.com> 1575581435 -0600
committer Skia Commit-Bot <skia-commit-bot@chromium.org> 1575658075 +0000

simplify GrCCPerFlushResources::recordCopyPathInstance

I should start off with, I don't know this code.  I may have
misunderstood what it's trying to do.  Is it well tested?

GCC pointed out that using memcpy() with CopyPathRange is a bad idea
since CopyPathRange is non-trivial (has an sk_sp).

Further, this appears to be an archetypical dangerous way to use
memcpy(), because the source and destination alias each other.

Am I understanding it correctly that we want to put the new entry at
fCurrCopyAtlasRangesIdx, sliding everything already past that index over
to make room?

I've tried to replace all this with

    1) push_back() to add a slot
    2) move_backwards() to slide everything over to the right
    3) = {...} to fill in the slot.

Step 2) is a no-op when fCurrCopyAtlasRangesIdx was at the end already.

Then now that we're no longer calling emplace_back, the type
CopyPathRange now no longer needs an explicit constructor.

This is the sort of thing I'm going for here...

    ~ $ cat test.cc
    #include <stdio.h>
    #include <vector>

    int main(int, char**) {
        for (int i = 0; i <= 5; i++) {
            std::vector<int> v = {1,2,3,4,5};

            v.push_back(0);
            std::move_backward(v.begin() + i,
                               v.end() - 1,
                               v.end());
            v[i] = 42;

            for (int x : v) {
                printf("%d ", x);
            }
            printf("\n");
        }
        return 0;
    }
    ~ $ clang++ test.cc && ./a.out
    42 1 2 3 4 5
    1 42 2 3 4 5
    1 2 42 3 4 5
    1 2 3 42 4 5
    1 2 3 4 42 5
    1 2 3 4 5 42

... which I guess is a roundabout way of spelling "insert()".  :P

Change-Id: I0a445aafa9a786ef8044243c7432f8597353a6b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258454
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>