Update SK_IMAGE_VERSION to test RAW

tools/dm_flags.py

 #
 # Copyright 2015 Google Inc.
 #
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 #
 
 #!/usr/bin/env python
 
 usage = '''
@@ skipping 141 matching lines @@
     blacklist.extend(['sp-8888', 'gm', '_', test])
   # skia:4703
   for test in ['image-cacherator-from-picture',
                'image-cacherator-from-raster',
                'image-cacherator-from-ctable']:
     blacklist.extend([       'sp-8888', 'gm', '_', test])
     blacklist.extend([      'pic-8888', 'gm', '_', test])
     blacklist.extend([   '2ndpic-8888', 'gm', '_', test])
     blacklist.extend(['serialize-8888', 'gm', '_', test])
 
+  # NexusPlayer runs out of memory running RAW codec tests

[scroggo, 2016/02/01 15:05:13]

Should we file a bug for this? Alternatively, we could try fixing this bot
another way. For example, we could not run with threads on the NexusPlayer -
that way we will only have one RAW file open at a time, which might fix the
problem (at the expense of making the bot run more slowly).

One thing that might help, by at least reducing the memory used by the encoded
data, would be to share it between various CodecSrc's (and AndroidCodecSrcs,
BRDSrcs...). The problem with this approach is that we don't want to create the
SkData initially and hang on to it, since that would mean holding on to it
longer than necessary (basically from when it's first opened til when the last
source using it unrefs it). I could imagine a set of weakly referenced SkDatas,
so a CodecSrc (etc) could first check to see if the file has already been opened
and ref it.

My first thought was that the NexusPlayer probably doesn't do anything
interestingly different, so it's okay to skip these tests, but clearly it has
less memory, which could point out a problem with decoding a single image.
(OTOH, we *know* there are problems with the amount of memory the SkRawCodec
holds, so maybe this gives us no more useful info.)

[msarett, 2016/02/01 15:43:11]

I like this idea, but I think it would probably be too slow.  How do we decide
how slow is "too slow"?
I like this idea the best.  When thinking about large streams, it seems
particularly bad that we read them into memory over and over again for all of
the different scales and tests etc.

How hard do you think this would be?
I think it's worth filing a bug that we don't have any x86 (or x86-64) Android
bots that run the RAW code.  Not sure whether the fix is to fix the bot or add a
new bot.

Regardless, I agree that there isn't any interesting/different behavior not
covered by other Android bots or other x86 bots.

+  if 'NexusPlayer' in bot:
+    r = ["arw", "cr2", "dng", "nef", "nrw", "orf", "raf", "rw2", "pef", "srw",
+         "ARW", "CR2", "DNG", "NEF", "NRW", "ORF", "RAF", "RW2", "PEF", "SRW"]
+    for raw_ext in r:
+      blacklist.extend(('_ image _ .%s' % raw_ext).split(' '))
+
   if blacklist:
     args.append('--blacklist')
     args.extend(blacklist)
 
   match = []
   if 'Valgrind' in bot: # skia:3021
     match.append('~Threaded')
 
   if 'GalaxyS3' in bot:  # skia:1699
     match.append('~WritePixels')
@@ skipping 62 matching lines @@
   if len(sys.argv) == 2 and sys.argv[1] == 'test':
     self_test()
     sys.exit(0)
 
   if len(sys.argv) != 3:
     print usage
     sys.exit(1)
 
   with open(sys.argv[1], 'w') as out:
     json.dump(get_args(sys.argv[2]), out)