2012-10-12 14:42:38 +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.
|
|
|
|
*/
|
2018-06-13 13:59:02 +00:00
|
|
|
|
2014-06-19 19:32:29 +00:00
|
|
|
#include "Benchmark.h"
|
2012-10-12 14:42:38 +00:00
|
|
|
#include "SkBitmap.h"
|
|
|
|
#include "SkCanvas.h"
|
|
|
|
#include "SkColorPriv.h"
|
2014-06-19 19:32:29 +00:00
|
|
|
#include "SkPaint.h"
|
2012-10-12 14:42:38 +00:00
|
|
|
#include "SkRandom.h"
|
|
|
|
#include "SkString.h"
|
2018-06-13 13:59:02 +00:00
|
|
|
#include "SkTo.h"
|
2012-10-12 14:42:38 +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) {
|
2012-10-12 14:42:38 +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);
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Variants for bitmaprect
|
|
|
|
src : entire bitmap, subset, fractional subset
|
|
|
|
dst : same size as src, diff size
|
|
|
|
paint : filter-p
|
|
|
|
*/
|
|
|
|
|
2014-06-19 19:32:29 +00:00
|
|
|
class BitmapRectBench : public Benchmark {
|
2013-10-31 17:28:30 +00:00
|
|
|
SkBitmap fBitmap;
|
|
|
|
bool fSlightMatrix;
|
|
|
|
uint8_t fAlpha;
|
2015-03-16 17:08:34 +00:00
|
|
|
SkFilterQuality fFilterQuality;
|
2013-10-31 17:28:30 +00:00
|
|
|
SkString fName;
|
|
|
|
SkRect fSrcR, fDstR;
|
|
|
|
|
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 const int kWidth = 128;
|
|
|
|
static const int kHeight = 128;
|
2012-10-12 14:42:38 +00:00
|
|
|
public:
|
2015-03-16 17:08:34 +00:00
|
|
|
BitmapRectBench(U8CPU alpha, SkFilterQuality filterQuality,
|
2013-10-31 17:28:30 +00:00
|
|
|
bool slightMatrix) {
|
2012-10-16 15:57:13 +00:00
|
|
|
fAlpha = SkToU8(alpha);
|
2015-03-16 17:08:34 +00:00
|
|
|
fFilterQuality = filterQuality;
|
2013-01-15 20:21:19 +00:00
|
|
|
fSlightMatrix = slightMatrix;
|
2012-10-16 15:57:13 +00:00
|
|
|
|
2014-06-10 02:52:07 +00:00
|
|
|
fBitmap.setInfo(SkImageInfo::MakeN32Premul(kWidth, kHeight));
|
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
|
|
|
fName.printf("bitmaprect_%02X_%sfilter_%s",
|
2013-10-31 17:28:30 +00:00
|
|
|
fAlpha,
|
2015-03-16 17:08:34 +00:00
|
|
|
kNone_SkFilterQuality == fFilterQuality ? "no" : "",
|
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
|
|
|
fSlightMatrix ? "trans" : "identity");
|
|
|
|
return fName.c_str();
|
|
|
|
}
|
2012-10-12 14:42:38 +00:00
|
|
|
|
2015-09-30 19:11:07 +00:00
|
|
|
void onDelayedSetup() override {
|
2012-10-12 14:42:38 +00:00
|
|
|
fBitmap.allocPixels();
|
2013-10-21 14:00:07 +00:00
|
|
|
fBitmap.setAlphaType(kOpaque_SkAlphaType);
|
2012-10-12 14:42:38 +00:00
|
|
|
fBitmap.eraseColor(SK_ColorBLACK);
|
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);
|
2012-10-13 02:01:56 +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
|
|
|
fSrcR.iset(0, 0, kWidth, kHeight);
|
|
|
|
fDstR.iset(0, 0, kWidth, kHeight);
|
2013-01-15 20:21:19 +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
|
|
|
if (fSlightMatrix) {
|
2013-01-15 20:21:19 +00:00
|
|
|
// want fractional translate
|
|
|
|
fDstR.offset(SK_Scalar1 / 3, SK_Scalar1 * 5 / 7);
|
|
|
|
// want enough to create a scale matrix, but not enough to scare
|
|
|
|
// off our sniffer which tries to see if the matrix is "effectively"
|
|
|
|
// translate-only.
|
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
|
|
|
fDstR.fRight += SK_Scalar1 / (kWidth * 60);
|
2013-01-15 20:21:19 +00:00
|
|
|
}
|
2012-10-12 14:42:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-10-01 16:43:39 +00:00
|
|
|
void onDraw(int loops, SkCanvas* canvas) override {
|
2013-09-09 20:09:12 +00:00
|
|
|
SkRandom rand;
|
2012-10-12 14:42:38 +00:00
|
|
|
|
|
|
|
SkPaint paint;
|
|
|
|
this->setupPaint(&paint);
|
2015-03-16 17:08:34 +00:00
|
|
|
paint.setFilterQuality(fFilterQuality);
|
2012-10-16 15:57:13 +00:00
|
|
|
paint.setAlpha(fAlpha);
|
2012-10-12 14:42:38 +00:00
|
|
|
|
2013-12-03 18:17:16 +00:00
|
|
|
for (int i = 0; i < loops; i++) {
|
2015-08-06 17:02:53 +00:00
|
|
|
canvas->drawBitmapRect(fBitmap, fSrcR, fDstR, &paint,
|
2015-07-17 14:09:43 +00:00
|
|
|
SkCanvas::kStrict_SrcRectConstraint);
|
2012-10-12 14:42:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
2014-06-19 19:32:29 +00:00
|
|
|
typedef Benchmark INHERITED;
|
2012-10-12 14:42:38 +00:00
|
|
|
};
|
|
|
|
|
2015-03-16 17:08:34 +00:00
|
|
|
DEF_BENCH(return new BitmapRectBench(0xFF, kNone_SkFilterQuality, false))
|
|
|
|
DEF_BENCH(return new BitmapRectBench(0x80, kNone_SkFilterQuality, false))
|
|
|
|
DEF_BENCH(return new BitmapRectBench(0xFF, kLow_SkFilterQuality, false))
|
|
|
|
DEF_BENCH(return new BitmapRectBench(0x80, kLow_SkFilterQuality, false))
|
2013-01-15 20:21:19 +00:00
|
|
|
|
2015-03-16 17:08:34 +00:00
|
|
|
DEF_BENCH(return new BitmapRectBench(0xFF, kNone_SkFilterQuality, true))
|
|
|
|
DEF_BENCH(return new BitmapRectBench(0xFF, kLow_SkFilterQuality, true))
|