Reason for revert:
Suspected in DM crashes, e.g.
2033 tasks left 344M peak 843ms tabl-cuteoverload_skp
Signal 11:
_sigtramp (+0x1a)
create_surface(CanvasConfig const&, GrContext*) (+0x1b2)
test_WritePixels(skiatest::Reporter*, GrContextFactory*) (+0x8d4)
skiatest::WritePixelsClass::onRun(skiatest::Reporter*) (+0x21)
skiatest::Test::run() (+0x7c)
DM::GpuTestTask::draw(GrContextFactory*) (+0x8c)
DM::GpuTask::run(GrContextFactory*) (+0xa6)
DM::TaskRunner::wait() (+0x7f)
dm_main() (+0x33f)
main (+0x27)
On all MacMini platforms (the following URL with -Mac{10.6,10.7,10.8}- and -{Debug,Release}):
http://build.chromium.org/p/client.skia/builders/Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Debug
Original issue's description:
> Add gpu support for Apple specific 'Vertex Arrays' functions
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/af000f469e1b0153ce445c96ca3d20e6d12224ccTBR=bsalomon@google.com,paraboul@gmail.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/750973003
Tested in Mozilla source tree. I tried to use skia build system, but it's up to the task for cross compilation.
SkHRESULT.cpp - Use proper file name (that matters on case sensitive OSes)
SkAtomics_win.h - Don't use pragma intrinsic on GCC (this causes massive warnings)
SkOSFile_win.cpp - This one is tricky. GCC doesn't allow (void*) casts in template argument constants and INVALID_HANDLE_VALUE looks like this:
((HANDLE)(LONG_PTR)-1)
where HANDLE is typedefed to void*. Changed the code to use LONG_PTR as template argument and cast it when needed.
BUG=skia:
R=bungeman@google.com, reed@google.com
Author: cjacek@gmail.com
Review URL: https://codereview.chromium.org/198643004
git-svn-id: http://skia.googlecode.com/svn/trunk@13862 2bbb7eff-a529-9590-31e7-b0007b416f81
When PDF uses fake bold text, it uses stroke and fill for the
text. After that, line is drawn. It creates new ContextEntry which
GraphicStateEntry has 0 fTextScaleX. Since fTextScaleX is 0,
GraphicStackState::updateDrawingState() doesn't update text fill mode or
the PDF page. When the normal text is drawn, it reuse the line's
ContextEntry because GraphicStateEntry::compareInitialState() returns
true. However, since the reused GraphicsStateEntry's fTextScaleX is 0,
the text fill mode is not updated to fill, and the text is drawn in
stroke and fill mode.
When the fTextScaleX is changed, we should not reuse GraphicStateEntry
even if ether of fTextScaleX is 0.
BUG=skia:2132
R=reed@google.com, vandebo@chromium.org, bungeman@google.com
Author: yuki.sekiguchi@access-company.com
Review URL: https://codereview.chromium.org/137923005
git-svn-id: http://skia.googlecode.com/svn/trunk@13369 2bbb7eff-a529-9590-31e7-b0007b416f81
