| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Tested by running on clang head + ubuntu 14.04:
GYP_DEFINES=”skia_gpu=0 skia_warnings_as_errors=1" tools/xsan_build thread dm BUILDTYPE=Release
out/Release/dm -v
BUG=skia:3386
Review URL: https://codereview.chromium.org/894833002
|
| |
|
|
|
|
|
|
|
|
| |
Depends on https://codereview.chromium.org/873753002/
Thumbs up to CLion for refactoring this for me.
BUG=skia:
Review URL: https://codereview.chromium.org/867963004
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
|
|
|
This change is here since previously color bitmap text was rendered using a
geometry processor in the coverage stage. The problem with this is that we
cannot correctly do xfer modes with this method. So I now make color bitmap text
draw using a color stage in the same was as a draw bitmap call.
One issue that arrises from this fix is that we end up adding this final color
processor after any previous color processors. Thus if we have a custom blend
implemented as a color processor it will be before this text one and we won't
blend correctly. This issue will get fixed once an xfer processor is fully
implemented. I have hacked a test locally to show that if we can add the text
color processor to the begining of the color stages we do blend correctly in all
cases (so the xfer processor will be a fix).
BUG=skia:
Review URL: https://codereview.chromium.org/689923004
|
rmistry
mtklein
egdaniel