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.
|
|
|
|
*/
|
2009-08-12 20:30:58 +00:00
|
|
|
#include "SkBenchmark.h"
|
|
|
|
#include "SkBitmap.h"
|
|
|
|
#include "SkCanvas.h"
|
|
|
|
#include "SkColorPriv.h"
|
|
|
|
#include "SkPaint.h"
|
|
|
|
#include "SkShader.h"
|
|
|
|
#include "SkString.h"
|
|
|
|
|
|
|
|
static const char* gConfigName[] = {
|
|
|
|
"ERROR", "a1", "a8", "index8", "565", "4444", "8888"
|
|
|
|
};
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2013-10-10 14:44:56 +00:00
|
|
|
static void convert_to_index666(const SkBitmap& src, SkBitmap* dst,
|
|
|
|
bool isOpaque) {
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-10-10 14:44:56 +00:00
|
|
|
SkAlphaType aType = isOpaque ? kOpaque_SkAlphaType : kPremul_SkAlphaType;
|
|
|
|
SkColorTable* ctable = new SkColorTable(storage, 216, aType);
|
2009-08-12 20:30:58 +00:00
|
|
|
dst->setConfig(SkBitmap::kIndex8_Config, src.width(), src.height());
|
|
|
|
dst->allocPixels(ctable);
|
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
class RepeatTileBench : public SkBenchmark {
|
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
|
|
|
SkPaint fPaint;
|
|
|
|
SkString fName;
|
|
|
|
SkBitmap fBitmap;
|
|
|
|
bool fIsOpaque;
|
|
|
|
SkBitmap::Config fConfig;
|
2009-08-12 20:30:58 +00:00
|
|
|
public:
|
2013-09-13 19:52:27 +00:00
|
|
|
RepeatTileBench(SkBitmap::Config c, bool isOpaque = false) {
|
2009-08-12 20:30:58 +00:00
|
|
|
const int w = 50;
|
|
|
|
const int h = 50;
|
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
|
|
|
fConfig = c;
|
|
|
|
fIsOpaque = isOpaque;
|
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
|
|
|
if (SkBitmap::kIndex8_Config == fConfig) {
|
|
|
|
fBitmap.setConfig(SkBitmap::kARGB_8888_Config, w, h);
|
2009-08-12 20:30:58 +00:00
|
|
|
} else {
|
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.setConfig(fConfig, w, 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
|
|
|
fName.printf("repeatTile_%s_%c",
|
|
|
|
gConfigName[fBitmap.config()], isOpaque ? 'X' : 'A');
|
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual const char* onGetName() SK_OVERRIDE {
|
|
|
|
return fName.c_str();
|
|
|
|
}
|
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
|
|
|
virtual void onPreDraw() SK_OVERRIDE {
|
|
|
|
fBitmap.allocPixels();
|
|
|
|
fBitmap.eraseColor(fIsOpaque ? SK_ColorWHITE : 0);
|
2013-10-21 14:00:07 +00:00
|
|
|
fBitmap.setAlphaType(fIsOpaque ?
|
|
|
|
kOpaque_SkAlphaType : kPremul_SkAlphaType);
|
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);
|
|
|
|
|
|
|
|
if (SkBitmap::kIndex8_Config == fConfig) {
|
2009-08-12 20:30:58 +00:00
|
|
|
SkBitmap tmp;
|
2013-10-10 14:44:56 +00:00
|
|
|
convert_to_index666(fBitmap, &tmp, fIsOpaque);
|
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
|
|
|
}
|
|
|
|
|
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
|
|
|
SkShader* s = SkShader::CreateBitmapShader(fBitmap,
|
2009-08-12 20:30:58 +00:00
|
|
|
SkShader::kRepeat_TileMode,
|
|
|
|
SkShader::kRepeat_TileMode);
|
|
|
|
fPaint.setShader(s)->unref();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-12-03 18:17:16 +00:00
|
|
|
virtual void onDraw(const int loops, SkCanvas* canvas) SK_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:
|
|
|
|
typedef SkBenchmark INHERITED;
|
|
|
|
};
|
|
|
|
|
2013-09-13 19:52:27 +00:00
|
|
|
DEF_BENCH(return new RepeatTileBench(SkBitmap::kARGB_8888_Config, true))
|
|
|
|
DEF_BENCH(return new RepeatTileBench(SkBitmap::kARGB_8888_Config, false))
|
|
|
|
DEF_BENCH(return new RepeatTileBench(SkBitmap::kRGB_565_Config))
|
|
|
|
DEF_BENCH(return new RepeatTileBench(SkBitmap::kIndex8_Config))
|