2011-07-28 14:26:00 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2011 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
2014-06-19 19:32:29 +00:00
|
|
|
#include "Benchmark.h"
|
2009-08-12 20:30:58 +00:00
|
|
|
#include "SkBitmap.h"
|
|
|
|
#include "SkCanvas.h"
|
|
|
|
#include "SkColorPriv.h"
|
|
|
|
#include "SkPaint.h"
|
|
|
|
#include "SkShader.h"
|
|
|
|
#include "SkString.h"
|
2014-06-10 02:52:07 +00:00
|
|
|
#include "sk_tool_utils.h"
|
2009-08-12 20:30:58 +00:00
|
|
|
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
static void draw_into_bitmap(const SkBitmap& bm) {
|
2009-08-12 20:30:58 +00:00
|
|
|
const int w = bm.width();
|
|
|
|
const int h = bm.height();
|
|
|
|
|
|
|
|
SkCanvas canvas(bm);
|
|
|
|
SkPaint p;
|
|
|
|
p.setAntiAlias(true);
|
|
|
|
p.setColor(SK_ColorRED);
|
|
|
|
canvas.drawCircle(SkIntToScalar(w)/2, SkIntToScalar(h)/2,
|
|
|
|
SkIntToScalar(SkMin32(w, h))*3/8, p);
|
2012-08-23 18:09:54 +00:00
|
|
|
|
2009-08-12 20:30:58 +00:00
|
|
|
SkRect r;
|
|
|
|
r.set(0, 0, SkIntToScalar(w), SkIntToScalar(h));
|
|
|
|
p.setStyle(SkPaint::kStroke_Style);
|
|
|
|
p.setStrokeWidth(SkIntToScalar(4));
|
|
|
|
p.setColor(SK_ColorBLUE);
|
|
|
|
canvas.drawRect(r, p);
|
|
|
|
}
|
|
|
|
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
static int conv_6_to_byte(int x) {
|
2009-08-12 20:30:58 +00:00
|
|
|
return x * 0xFF / 5;
|
|
|
|
}
|
|
|
|
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
static int conv_byte_to_6(int x) {
|
2009-08-12 20:30:58 +00:00
|
|
|
return x * 5 / 255;
|
|
|
|
}
|
|
|
|
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
static uint8_t compute_666_index(SkPMColor c) {
|
2009-08-12 20:30:58 +00:00
|
|
|
int r = SkGetPackedR32(c);
|
|
|
|
int g = SkGetPackedG32(c);
|
|
|
|
int b = SkGetPackedB32(c);
|
2012-08-23 18:09:54 +00:00
|
|
|
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
return conv_byte_to_6(r) * 36 + conv_byte_to_6(g) * 6 + conv_byte_to_6(b);
|
2009-08-12 20:30:58 +00:00
|
|
|
}
|
|
|
|
|
2014-06-10 02:52:07 +00:00
|
|
|
static void convert_to_index666(const SkBitmap& src, SkBitmap* dst) {
|
2013-10-10 14:44:56 +00:00
|
|
|
SkPMColor storage[216];
|
|
|
|
SkPMColor* colors = storage;
|
2009-08-12 20:30:58 +00:00
|
|
|
// rrr ggg bbb
|
|
|
|
for (int r = 0; r < 6; r++) {
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
int rr = conv_6_to_byte(r);
|
2009-08-12 20:30:58 +00:00
|
|
|
for (int g = 0; g < 6; g++) {
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
int gg = conv_6_to_byte(g);
|
2009-08-12 20:30:58 +00:00
|
|
|
for (int b = 0; b < 6; b++) {
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
int bb = conv_6_to_byte(b);
|
2009-08-12 20:30:58 +00:00
|
|
|
*colors++ = SkPreMultiplyARGB(0xFF, rr, gg, bb);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-09-29 19:10:27 +00:00
|
|
|
SkColorTable* ctable = new SkColorTable(storage, 216);
|
2014-06-10 02:52:07 +00:00
|
|
|
dst->allocPixels(SkImageInfo::Make(src.width(), src.height(),
|
|
|
|
kIndex_8_SkColorType, kOpaque_SkAlphaType),
|
2015-08-27 14:41:13 +00:00
|
|
|
nullptr, ctable);
|
2009-08-12 20:30:58 +00:00
|
|
|
ctable->unref();
|
2012-08-23 18:09:54 +00:00
|
|
|
|
2009-08-12 20:30:58 +00:00
|
|
|
SkAutoLockPixels alps(src);
|
|
|
|
SkAutoLockPixels alpd(*dst);
|
|
|
|
|
|
|
|
for (int y = 0; y < src.height(); y++) {
|
|
|
|
const SkPMColor* srcP = src.getAddr32(0, y);
|
|
|
|
uint8_t* dstP = dst->getAddr8(0, y);
|
|
|
|
for (int x = src.width() - 1; x >= 0; --x) {
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
*dstP++ = compute_666_index(*srcP++);
|
2009-08-12 20:30:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-06-19 19:32:29 +00:00
|
|
|
class RepeatTileBench : public Benchmark {
|
2014-06-10 02:52:07 +00:00
|
|
|
const SkColorType fColorType;
|
|
|
|
const SkAlphaType fAlphaType;
|
|
|
|
SkPaint fPaint;
|
|
|
|
SkString fName;
|
|
|
|
SkBitmap fBitmap;
|
2009-08-12 20:30:58 +00:00
|
|
|
public:
|
2014-06-10 02:52:07 +00:00
|
|
|
RepeatTileBench(SkColorType ct, SkAlphaType at = kPremul_SkAlphaType)
|
|
|
|
: fColorType(ct), fAlphaType(at)
|
|
|
|
{
|
2009-08-12 20:30:58 +00:00
|
|
|
const int w = 50;
|
|
|
|
const int h = 50;
|
|
|
|
|
2014-06-10 02:52:07 +00:00
|
|
|
if (kIndex_8_SkColorType == ct) {
|
|
|
|
fBitmap.setInfo(SkImageInfo::MakeN32(w, h, at));
|
2009-08-12 20:30:58 +00:00
|
|
|
} else {
|
2014-06-10 02:52:07 +00:00
|
|
|
fBitmap.setInfo(SkImageInfo::Make(w, h, ct, at));
|
2009-08-12 20:30:58 +00:00
|
|
|
}
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
fName.printf("repeatTile_%s_%c",
|
2014-06-10 02:52:07 +00:00
|
|
|
sk_tool_utils::colortype_name(ct), kOpaque_SkAlphaType == at ? 'X' : 'A');
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
2015-03-26 01:17:31 +00:00
|
|
|
const char* onGetName() override {
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
return fName.c_str();
|
|
|
|
}
|
2012-08-23 18:09:54 +00:00
|
|
|
|
2015-09-30 19:11:07 +00:00
|
|
|
void onDelayedSetup() override {
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
fBitmap.allocPixels();
|
2014-06-10 02:52:07 +00:00
|
|
|
fBitmap.eraseColor(kOpaque_SkAlphaType == fAlphaType ? SK_ColorWHITE : 0);
|
2009-08-12 20:30:58 +00:00
|
|
|
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
draw_into_bitmap(fBitmap);
|
|
|
|
|
2014-06-10 02:52:07 +00:00
|
|
|
if (kIndex_8_SkColorType == fColorType) {
|
2009-08-12 20:30:58 +00:00
|
|
|
SkBitmap tmp;
|
2014-06-10 02:52:07 +00:00
|
|
|
convert_to_index666(fBitmap, &tmp);
|
When skia run bench cases to test performance, it will run constructors for all cases one by one, then getName to skip unnecessary cases according to command line parameters, so these constructors should be lightweight enough to avoid redundant computing. Unfortunately, some constructors contain intensive computing/rendering. They are very heavy, maybe much heavier than need-to-run bench case itself. And these redundant computation will be run every time you run bench, even you just test a single simple case. Moreover, it will mislead the real hotspot/bottleneck of the case itself.
For example, run a lightweight case, say, region_intersectsrgn_16, the hot spots are gles operation, SuperBlitter, SkRTree... introduced by irrelevant cases' constructors. These redundant computation will mislead performance tuning.
So we can move these intensive computation to onPreDraw() of these case. They will be executed only if this case should be run.
R=reed@google.com, robertphillips@google.com, humper@google.com, tomhudson@chromium.org
Author: yunchao.he@intel.com
Review URL: https://chromiumcodereview.appspot.com/20997003
git-svn-id: http://skia.googlecode.com/svn/trunk@10486 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-08-01 15:58:07 +00:00
|
|
|
fBitmap = tmp;
|
2009-08-12 20:30:58 +00:00
|
|
|
}
|
|
|
|
|
2016-03-14 19:22:10 +00:00
|
|
|
fPaint.setShader(SkShader::MakeBitmapShader(fBitmap,
|
|
|
|
SkShader::kRepeat_TileMode,
|
|
|
|
SkShader::kRepeat_TileMode));
|
2009-08-12 20:30:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-10-01 16:43:39 +00:00
|
|
|
void onDraw(int loops, SkCanvas* canvas) override {
|
2009-08-12 20:30:58 +00:00
|
|
|
SkPaint paint(fPaint);
|
|
|
|
this->setupPaint(&paint);
|
|
|
|
|
2013-12-03 18:17:16 +00:00
|
|
|
for (int i = 0; i < loops; i++) {
|
2009-08-12 20:30:58 +00:00
|
|
|
canvas->drawPaint(paint);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
2014-06-19 19:32:29 +00:00
|
|
|
typedef Benchmark INHERITED;
|
2009-08-12 20:30:58 +00:00
|
|
|
};
|
|
|
|
|
2014-06-10 02:52:07 +00:00
|
|
|
DEF_BENCH(return new RepeatTileBench(kN32_SkColorType, kOpaque_SkAlphaType))
|
|
|
|
DEF_BENCH(return new RepeatTileBench(kN32_SkColorType, kPremul_SkAlphaType))
|
|
|
|
DEF_BENCH(return new RepeatTileBench(kRGB_565_SkColorType, kOpaque_SkAlphaType))
|
|
|
|
DEF_BENCH(return new RepeatTileBench(kIndex_8_SkColorType, kPremul_SkAlphaType))
|