Re: Issue 121780 in chromium: 2d canvas drawImage draws only black

[chro...@googlecode.com]

Comment #4 on issue 121780 by tomhud...@chromium.org: 2d canvas drawImage
draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

When I attempt to reproduce on Win7, with both files on the local
filesystem, the counter never increments/image never loads and the console
displays "Uncaught Error: SECURITY_ERR: DOM Exception 18"

[chro...@googlecode.com]

Comment #8 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

It appears that garbage image I was seeing on my MBP is a dupe of 121528
but the black image seen by thrasher@ is not.

I was able to get a repro on Win7. I loaded the attached repro in four tabs
different tabs at once and one of them generated a black blob result.

[chro...@googlecode.com]

Comment #18 on issue 121780 by wiltz...@chromium.org: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Cool, thanks for the update!

[chro...@googlecode.com]

Comment #20 on issue 121780 by g...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

clearing in chunks sounds like a good idea
http://code.google.com/p/chromium/issues/detail?id=122920

[chro...@googlecode.com]

Comment #22 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

#21, If you see garbage then it is Issue 121528. If it is black then it is
probably this issue. In either case I believe if instead of drawing the
large image in a single draw you tiled the draw at say 1Kx1K or 2Kx2K
chunks you would work around these issues.

[chro...@googlecode.com]

Comment #23 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Thanks for the response! When you say 1Kx1K do you mean pixels? We
definitely see the issues at sub-1000x1000 images drawn directly to canvas
so possibly you mean something else like memory size?

[chro...@googlecode.com]

Comment #24 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I did mean pixels. I wonder if you're seeing a different issue. Do you have
a repro case that you could share?

[chro...@googlecode.com]

Comment #25 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I will try to come up with something pared down but the issue can be
reliably reproduced by going to this site and clicking "Try the web demo"
http://www.aviary.com/

The photo editor does a drawImage with this image:
http://images.aviary.com/imagesv5/feather_default.jpg (841x600)

Into a canvas sized 800x570

I have only seen it on one machine here, a 15" MacBook Pro with Core i7 and
an ATI Radeon HD 6750 1024MB graphics card.

[chro...@googlecode.com]

Comment #26 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

#25, I don't see it on a Mac Pro witha HD 5770. There was an Mac/ATI
specific issue that was resolved recently. I'm having trouble finding it
right now but will update again when I find the issue. Do you see repros on
the Canary channel? (You can install it along side your stable install)

The tiled clear has just landed and the ANGLE change made it into chromium.
I believe we should be in a much better place with the original bug. We
should use less memory and not crash. The performance still leaves
something to be desired. I'm looking into whether using the chromium
extension to map a texture for write access will pay off here.

[chro...@googlecode.com]

Comment #29 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

One other thing to note: If I load repro.html in a bunch of tabs at once
some will draw black for part of the image. The issue is that ANGLE OOMs
creating its shadow copy of the tile textures. Vangelis informs me that
there is an ANGLE task to remove these copies.

[chro...@googlecode.com]

Comment #30 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

#26 This happens 100% of the time for me on the Macbook Pro (15" MacBook
Pro with Core i7 and an ATI Radeon HD 6750 1024MB graphics card)

It happens on Canary as well, 100% of the time.

Using --disable-accelerated-2d-canvas stops this from happening.

Is there anyone to contact about a the possibility of a web app-side fix if
a real fix is not in the pipeline (Canary)? Or any channels for further
support?

This has a significant impact on our business (HTML5 photo editor using
canvas). We need to take some sort of action with our users but our hands
seem tied.

[chro...@googlecode.com]

Updates:
Cc: k...@chromium.org

Comment #31 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Maybe related to gpu switching?

[chro...@googlecode.com]

Comment #37 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

chis@ : We were able to repro the issue in aviary.com on a mac pro with
switchable graphics. You can get around it by forcing the discrete gpu on
(however, not with gfxCardStatus that I mentioned earlier. Please make
sure that gfxCardStatus, if running, is set to automatic switching).
Simply go to the system preferences, under Energy Saver and disable
automatic graphics switching. You'll need to restart chrome for the setting
to take effect.

Seems like the same root cause as issue 125246 .

[chro...@googlecode.com]

Comment #38 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

#37 Thanks for the info! I wasn't able to get ahold of the macbook to try
testing gpu switching so this is good to know.

So this is slightly better than asking users to use commandline to disable
the hardware accel, but is there anything that can be done at the
window/document layer? (JavaScript or CSS).

[chro...@googlecode.com]

Comment #39 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

We're looking into putting a proper fix in place.

What may work in the meantime would be to, before getting the "2d" context
out of your real canvas, create another canvas (could be 1x1, hidden, etc)
in the page and do a getContext("experimental-webgl") on it. This should
force a switch to the discrete gpu.

It's a bit nasty so sorry in advance...

[chro...@googlecode.com]

Comment #40 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Thanks for the idea, I tried that and I was able to read information from
it. Unfortunately it didn't seem to have an effect on the rendering.
Anything additional you have to do beyond this?

var gpuCanvas = document.createElement('canvas');
gpuCanvas.width = gpuCanvas.height = 1;
gpuCanvas.getContext("experimental-webgl");

Does the canvas have to be appended to the DOM? It's quite likely I'm
actually experiencing the other issue -- usually what is on the canvas
is "garbage" rendering from other elements on the webpage.

[chro...@googlecode.com]

Comment #41 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

To the best of my knowledge, the above hack should be sufficient as a
workaround.

Double-check to make sure this code is executing before you call
getContext('2d') against your primary canvas.

[chro...@googlecode.com]

Comment #42 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

#39 #41 I think the hack is working in that it forces the mac into discrete
mode.

However, it seems that the bug only happens on discrete mode so I actually
would need the opposite hack, to put me back on integrated graphics. Any
chance there is a way to do that?

So as an update, it seems like my particular issue is NOT related to
graphics card switching, but instead directly related to the discrete
chipset

Thanks again!

[chro...@googlecode.com]

Comment #43 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

When we tried it here it looked like the site worked properly on the
discrete card. It was only when automatic card switching was enabled.

[chro...@googlecode.com]

Comment #44 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

@chris: sorry. I misdiagnosed the issue. We're investigating multiple
issues related both to accelerated 2D canvas and dynamic graphics switching.

Unfortunately, you're right, the above workaround won't help you. I can
confirm that forcing the use of the discrete chip actually forces
http://www.aviary.com/ to render the image black. We need to figure out why
the accelerated 2D canvas implementation is failing on this GPU.

[chro...@googlecode.com]

Comment #45 on issue 121780 by ch...@worth1000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Here are details on the two graphics cards on the machine I am using to
repro:

Integrated
http://cl.ly/1b1u200d1d3e3W12023r
Discrete
http://cl.ly/2R1c3J3l1F2Z2K0R0m3J

[chro...@googlecode.com]

Comment #46 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I can't reproduce the http://www.aviary.com black image on a MacMini with a
Radeon HD 6630M.

[chro...@googlecode.com]

Comment #47 on issue 121780 by christia...@ff0000.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I am able to reproduce this issue (canvas renders as black rectangle) in
Chrome 19 Macbook pro. Not all canvas elements on the page are black.
Closing / reopening tab fixes issue. getContext("webgl-experimental")
unfortunately does not fix the issue.

[chro...@googlecode.com]

Comment #48 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I have a MBP with the 6750 and I can reproduce the issue at
www.aerotwist.com.

[chro...@googlecode.com]

Updates:
Cc: le...@chromium.org

Comment #50 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Oh, this may be new with the introduction of fractional layout.
+levi

[chro...@googlecode.com]

Comment #51 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

The vertex shader that is failing looks like this:

attribute vec4 a_position;
attribute vec2 a_texCoord;
uniform mat4 matrix;
uniform vec4 texTransform;
varying vec2 v_texCoord;

void main() {
gl_Position = matrix * a_position;
v_texCoord = a_texCoord * texTransform.zw + texTransform.xy;
}

[chro...@googlecode.com]

Comment #52 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

context->getShaderInfoLog(shader); returns an empty string.

[chro...@googlecode.com]

Updates:
Cc: e...@chromium.org

Comment #53 on issue 121780 by le...@chromium.org: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #54 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

It's this shader used by the compositor:

http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/graphics/chromium/ShaderChromium.cpp&exact_package=chromium&q=%22v_texCoord%20=%20a_texCoord%20*%20texTransform.zw%20%2B%20texTransform.xy;%22&l=137

I'm not seeing any obvious reasons why it would be failing to compile
though. I guess we could try something simple such as replacing a_texCoord
by a_texCoord.xy .

Ken, Gregg, do you see anything strange here?

[chro...@googlecode.com]

Comment #55 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

No. I copied that shader into a WebGL app and it compiles successfully on
the target machine (AMD Radeon HD 6490M).

[chro...@googlecode.com]

Comment #56 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I added a bunch of printfs to the gpu service side and as far as I can tell
it never sees a shader that doesn't compile. Yet, I definitely get into
this block on the client side:
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/graphics/chromium/ProgramBinding.cpp&l=82

[chro...@googlecode.com]

Comment #57 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Brian, does this happen the first time textureProgramFlip gets compiled or
at some random point later on?

[chro...@googlecode.com]

Comment #58 on issue 121780 by g...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

If you have a debug build you should be able to see every client side call
and return value with

--enable-gpu-client-logging &>dump.txt

It will spew a ton but you can see if the client side thinks the shader
failed to compile vs the service side.

[chro...@googlecode.com]

Comment #59 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

It appears to happen the first time textureProgramFlip is used. Here is
tail of the spew with --enable-gpu-client-logging and some other printfs I
added.

[44033:-1394527552:30243499826088:INFO:gles2_implementation.cc(978)]
[0x6c6ad0f0] glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, 0)
[44033:-1394527552:30243499836552:INFO:gles2_implementation.cc(783)]
[0x6c6ad0f0] glEnable(GL_SCISSOR_TEST)
[44033:-1394527552:30243499845889:INFO:gles2_implementation_autogen.h(949)]
[0x6c6ad0f0] glScissor(0, 0, 1050, 635)
[44033:-1394527552:30243499855069:INFO:gles2_implementation.cc(783)]
[0x6c6ad0f0] glEnable(GL_BLEND)
BPS: TPF bind
BPS: TPF()
BPS: TPF create
[44033:-1394527552:30243499907018:INFO:gles2_implementation_autogen.h(218)]
[0x6c6ad0f0] glCreateShader(GL_VERTEX_SHADER)
[44033:-1394527552:30243499919272:INFO:gles2_implementation_autogen.h(223)]
returned 13
[44033:-1394527552:30243499936906:INFO:gles2_implementation.cc(1421)]
[0x6c6ad0f0] glShaderSource(13, 1, 0xc006df4c, 0xc006df48)
[44033:-1394527552:30243499945705:INFO:gles2_implementation.cc(1427)] 0:
---

attribute vec4 a_position; attribute vec2 a_texCoord; uniform mat4 matrix;
uniform vec4 texTransform; varying vec2 v_texCoord; void main() {
gl_Position = matrix * a_position; v_texCoord = a_texCoord *
texTransform.zw + texTransform.xy; }

---
[44033:-1394527552:30243500003980:INFO:gles2_implementation_autogen.h(159)]
[0x6c6ad0f0] glCompileShader(13)
[44033:-1394527552:30243500016749:INFO:gles2_implementation_autogen.h(670)]
[0x6c6ad0f0] glGetShaderiv(13, GL_COMPILE_STATUS, 0xc006e044)
[44033:-1394527552:30243500137614:INFO:gles2_implementation_autogen.h(670)]
[0x6c6ad0f0] glGetShaderiv(13, GL_INFO_LOG_LENGTH, 0xc006df5c)

---
Shader 13 Compiled: 0 Log:

----------------------------

attribute vec4 a_position; attribute vec2 a_texCoord; uniform mat4 matrix;
uniform vec4 texTransform; varying vec2 v_texCoord; void main() {
gl_Position = matrix * a_position; v_texCoord = a_texCoord *
texTransform.zw + texTransform.xy; }

----------------------------
Assertion failed: (0), function loadShader,
file ../../third_party/WebKit/Source/WebCore/platform/graphics/chromium/ProgramBinding.cpp,
line 87.

[chro...@googlecode.com]

Updates:
Cc: apatr...@chromium.org jbau...@chromium.org

Comment #61 on issue 121780 by vange...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Al, John, any ideas on what may be happening here?

[chro...@googlecode.com]

Comment #62 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Brian: which conditional exactly? The link above points to
CommandBufferProxyImpl::FlushSync but it has three conditionals within.

[chro...@googlecode.com]

Comment #63 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Sorry, I thought the link would preserve the line I had highlighted. I
meant line 205 if (last_known_get == last_state_.get_offset) {

[chro...@googlecode.com]

Comment #64 on issue 121780 by jbau...@chromium.org: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

That conditional will likely be true at least one time. If the service side
hasn't finished processing all the queued up 3d commands at that point
(which is likely if we're inside getShaderiv), FlushSync should be called
again until it has. If last_state_.get_offset is equal to last_put_offset_
then all the commands have been processed.


I'd recommend looking at GLES2DecoderImpl::DoGetShaderiv on the service
side first.

[chro...@googlecode.com]

Comment #65 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I set a renderer breakpoint at the point where textureProgramFlip is first
created (http://goo.gl/GkVYF). I then set a breakpoint in the GPU process
at GLES2DecoderImpl::DoGetShaderiv (http://goo.gl/gW91V). The renderer gets
to the point where it thinks shader compilation has failed in
ProgramBindingBase::loadShader() (http://goo.gl/bEPWi) without the GPU
process breakpoint being hit. This jives with the log spew from
--enable-gpu-service-logging where the GPU proc seems to never process the
commands from the client issued for some stretch up until the failed shader
assertion.

[chro...@googlecode.com]

Comment #66 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

The GPU process's stack when textureProgramFlip is about to be created
looks like this:

#2 0x9841cc7a in __CFRunLoopServiceMachPort ()
#3 0x98425da4 in __CFRunLoopRun ()
#4 0x9842547c in CFRunLoopRunSpecific ()
#5 0x98425328 in CFRunLoopRunInMode ()
#6 0x9595117f in RunCurrentEventLoopInMode ()
#7 0x959584e7 in ReceiveNextEventCommon ()
#8 0x95958356 in BlockUntilNextEventMatchingListInMode ()
#9 0x94988a9c in _DPSNextEvent ()
#10 0x94988306 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#11 0x94984675 in -[NSApplication run] ()
#12 0x027b8fee in base::MessagePumpNSApplication::DoRun (this=0x1324dcf0,
delegate=0xc0069fb0) at ../../base/message_pump_mac.mm:542
#13 0x027b7ef2 in base::MessagePumpCFRunLoopBase::Run (this=0x1324dcf0,
delegate=0xc0069fb0) at ../../base/message_pump_mac.mm:179
#14 0x0285acb2 in MessageLoop::RunInternal (this=0xc0069fb0)
at ../../base/message_loop.cc:422
#15 0x02859fcb in MessageLoop::RunHandler (this=0xc0069fb0)
at ../../base/message_loop.cc:395
#16 0x02859f10 in MessageLoop::Run (this=0xc0069fb0)
at ../../base/message_loop.cc:305
#17 0x01fa0fda in GpuMain (parameters=@0xc006a658)
at ../../content/gpu/gpu_main.cc:205
#18 0x063fbed4 in (anonymous namespace)::RunNamedProcessTypeMain
(process_type=@0xc006a678, main_function_params=@0xc006a658,
delegate=0xc006a8a8)
at ../../content/app/content_main_runner.cc:318
#19 0x063fba78 in (anonymous namespace)::ContentMainRunnerImpl::Run
(this=0x6b942390) at ../../content/app/content_main_runner.cc:575
#20 0x063fa8e7 in content::ContentMain (argc=12, argv=0xc006a91c,
delegate=0xc006a8a8) at ../../content/app/content_main.cc:35
#21 0x0007239b in ChromeMain (argc=12, argv=0xc006a91c)
at ../../chrome/app/chrome_main.cc:32
#22 0x0006cf7b in main (argc=12, argv=0xc006a91c)
at ../../chrome/app/chrome_exe_main_mac.cc:16

To my non-expert eyes this looks like it is in a msg loop waiting for some
work to do and not suspicious. According to the service side logging, the
last command processed was a flush.

I also confirmed that the GPU process breakpoint in DoGetShaderiv is hit
when the renderer compiles other, earlier shaders via
ProgramBindingBase::loadShader.

[chro...@googlecode.com]

Comment #67 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I was incorrect before about the "last_known_get == last_state_.get_offset"
test. It is false the first time in when processing the FlushSync for
getShaderiv.

I enabled IPC logging using environment variable CHROME_IPC_LOGGING=1. I
see a mix of gpu service, gpu client, and IPC log messages up until the
final flush before the shader compile failure. After the flush there are no
IPC messages until after the renderer crashes on the failed shader assert.

I attached a log file from the run. It contains a mix of gpu service, gpu
client, and ipc logs as well as a few printfs() I added. It begins just
before the final flush and ends after the cleanup from the crashed renderer.


Attachments:
log.txt 58.4 KB

[chro...@googlecode.com]

Comment #68 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I've attached a full log with gpu client, gpu service, and ipc logging.

The command line that generated it was:
CHROME_IPC_LOGGING=1 out/Debug/Chromium.app/Contents/MacOS/Chromium
--enable-logging=stderr --disable-gpu-sandboxox
--enable-gpu-client-logging --enable-gpu-service-logging 2>
aerotwist_log.txt

The assertion that failed at the end of the log is one I inserted in
ProgramBindingBase::loadShader in the if (!compiled) block.


Attachments:
aerotwist_log.txt 3.0 MB

[chro...@googlecode.com]

Comment #69 on issue 121780 by g...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Here's an annotated version of the log with the various contexts

SkiaContext (renderer)
CompositorContext (renderer)
SkiaGPUContext (gpu)
CompositorGPUContext (gpu)

marked for each log entry

I'm seeing something I don't understand. At line 26851 the SkiaContext
(renderer) issues glCheckFramebuffer() which is a blocking call. The
service executes a ton of queued commands at that point. It finally gets to
the glCheckFramebufferStatus at line 27830

The next command issued on the SkiaContext is glReadPixels() at line 27846
but I can see above that glDrawElements is being called on
SkiaServiceContext at line 27842.

Either the log is missing lines or else something else is seriously wrong
at that point.


Attachments:
aerotwist_log_annotated.txt 3.1 MB

[chro...@googlecode.com]

Comment #72 on issue 121780 by g...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Of course that doesn't make a whole lot of sense if it's working other
places :-(

[chro...@googlecode.com]

Comment #73 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Skia and WebKit are supposed to both be going through interfaces that make
their contexts current at each call. Though maybe there is some code that
doesn't do this. The repro does seem somewhat timing dependent. Every now
and again I don't get repro and it seems somewhat related to whether other
tabs also open at browser launch.

[chro...@googlecode.com]

Comment #74 on issue 121780 by g...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Any idea what code is needing to do a glReadPixels? Is that the
Thumbnailer?

[chro...@googlecode.com]

Comment #75 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Yup, thumbnailer. The readpixels is here:

http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp&exact_package=chromium&l=1269

I set a breakpoint and it's hit before some but not all repros so I don't
think it is related.

[chro...@googlecode.com]

Comment #76 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I commented out the creation of Skia objects that talk to GL and I still
get the repro. The shared gc3d still gets created; it's just never used by
skia.

Attachments:
aerotwist_no_skiagl_log.txt 1.0 MB

[chro...@googlecode.com]

Comment #77 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

When the SGC3D is created the GPU process actually shuts down a GL channel
/ context.

The GPU process is here:

#2 0x029a5194 in gpu::gles2::GLES2DecoderImpl::Destroy (this=0x59663fb0,
have_context=true)
at ../../gpu/command_buffer/service/gles2_cmd_decoder.cc:2756
#3 0x060d3df0 in GpuCommandBufferStub::Destroy (this=0x59663920)
at ../../content/common/gpu/gpu_command_buffer_stub.cc:219
#4 0x060d3a34 in GpuCommandBufferStub::~GpuCommandBufferStub
(this=0x59663920) at ../../content/common/gpu/gpu_command_buffer_stub.cc:77
#5 0x060d395b in GpuCommandBufferStub::~GpuCommandBufferStub
(this=0x59663920) at ../../content/common/gpu/gpu_command_buffer_stub.cc:76
#6 0x060d38fe in GpuCommandBufferStub::~GpuCommandBufferStub
(this=0x59663920) at ../../content/common/gpu/gpu_command_buffer_stub.cc:76
#7 0x060c9154 in IDMap<GpuCommandBufferStub,
(IDMapOwnershipSemantics)1>::Releaser<(IDMapOwnershipSemantics)1,
0>::release_all (table=0x132716b0) at id_map.h:184
#8 0x060c9070 in IDMap<GpuCommandBufferStub,
(IDMapOwnershipSemantics)1>::~IDMap (this=0x13271658) at id_map.h:52
#9 0x060c2c4b in IDMap<GpuCommandBufferStub,
(IDMapOwnershipSemantics)1>::~IDMap (this=0x13271658) at id_map.h:47
#10 0x060c07f0 in GpuChannel::~GpuChannel (this=0x13271590)
at ../../content/common/gpu/gpu_channel.cc:245
#11 0x060c073b in GpuChannel::~GpuChannel (this=0x13271590)
at ../../content/common/gpu/gpu_channel.cc:245
#12 0x060c06de in GpuChannel::~GpuChannel (this=0x13271590)
at ../../content/common/gpu/gpu_channel.cc:245
#13 0x060cf15d in base::RefCountedThreadSafe<GpuChannel,
base::DefaultRefCountedThreadSafeTraits<GpuChannel> >::DeleteInternal
(x=0x13271590) at ref_counted.h:151
#14 0x060cf0fb in
base::DefaultRefCountedThreadSafeTraits<GpuChannel>::Destruct
(x=0x13271590) at ref_counted.h:116
#15 0x060cf0ad in base::RefCountedThreadSafe<GpuChannel,
base::DefaultRefCountedThreadSafeTraits<GpuChannel> >::Release
(this=0x13271598) at ref_counted.h:145
#16 0x060d0b85 in scoped_refptr<GpuChannel>::~scoped_refptr
(this=0x132719f8) at ref_counted.h:243
#17 0x060cd79b in scoped_refptr<GpuChannel>::~scoped_refptr
(this=0x132719f8) at ref_counted.h:241
#18 0x060cec51 in std::pair<int const, scoped_refptr<GpuChannel> >::~pair
(this=0x132719f4) at stl_pair.h:68
#19 0x060cebfb in std::pair<int const, scoped_refptr<GpuChannel> >::~pair
(this=0x132719f4) at stl_pair.h:68
#20 0x060ce9f2 in __gnu_cxx::new_allocator<std::pair<int const,
scoped_refptr<GpuChannel> > >::destroy (this=0xc008cdf0, __p=0x132719f4) at
new_allocator.h:110
#21 0x060ce917 in __gnu_cxx::hashtable<std::pair<int const,
scoped_refptr<GpuChannel> >, int, __gnu_cxx::hash<int>,
std::_Select1st<std::pair<int const, scoped_refptr<GpuChannel> > >,
std::equal_to<int>, std::allocator<scoped_refptr<GpuChannel> >
>::_M_delete_node (this=0x13270ea0, __n=0x132719f0) at hashtable.h:621
#22 0x060d14df in __gnu_cxx::hashtable<std::pair<int const,
scoped_refptr<GpuChannel> >, int, __gnu_cxx::hash<int>,
std::_Select1st<std::pair<int const, scoped_refptr<GpuChannel> > >,
std::equal_to<int>, std::allocator<scoped_refptr<GpuChannel> > >::erase
(this=0x13270ea0, __key=@0xc008cea8) at hashtable.h:897
#23 0x060ccdd9 in __gnu_cxx::hash_map<int, scoped_refptr<GpuChannel>,
__gnu_cxx::hash<int>, std::equal_to<int>,
std::allocator<scoped_refptr<GpuChannel> > >::erase (this=0x13270ea0,
__key=@0xc008cea8) at hash_map:239
#24 0x060cba7f in GpuChannelManager::RemoveChannel (this=0x13270e80,
client_id=2) at ../../content/common/gpu/gpu_channel_manager.cc:35
#25 0x060c12d5 in GpuChannel::OnCloseChannel (this=0x13271590)
at ../../content/common/gpu/gpu_channel.cc:428
#26 0x060c3098 in IPC::Message::Dispatch<GpuChannel, GpuChannel>
(msg=0x13272ef8, obj=0x13271590, sender=0x13271590, func={ptr = 101454496,
ptr = 0}) at ipc_message.h:158
#27 0x060bf2e7 in GpuChannel::OnControlMessageReceived (this=0x13271590,
msg=@0x13272ef8) at ../../content/common/gpu/gpu_channel.cc:263
#28 0x060bec81 in GpuChannel::OnMessageReceived (this=0x13271590,
message=@0x13272ef8) at ../../content/common/gpu/gpu_channel.cc:102
#29 0x0243b2b9 in IPC::ChannelProxy::Context::OnDispatchMessage
(this=0x132717f0, message=@0x13272ef8) at ../../ipc/ipc_channel_proxy.cc:249

while at the same time the renderer proc is here:

#0 0x9a8a083e in __psynch_cvwait ()
#1 0x99315e21 in _pthread_cond_wait ()
#2 0x992c642c in pthread_cond_wait$UNIX2003 ()
#3 0x0288539d in base::ConditionVariable::Wait (this=0xc0010650)
at ../../base/synchronization/condition_variable_posix.cc:37#4 0x02887d95
in base::WaitableEvent::WaitMany (raw_waitables=0xc0010958, count=2)
at ../../base/synchronization/waitable_event_posix.cc:273
#5 0x023d59a3 in IPC::SyncChannel::WaitForReply (context=0x6d327900,
pump_messages_event=0x0) at ../../ipc/ipc_sync_channel.cc:470
#6 0x023d58b8 in IPC::SyncChannel::SendWithTimeout (this=0x6d3276f0,
message=0x6b473490, timeout_ms=-1) at ../../ipc/ipc_sync_channel.cc:454
#7 0x023d54e2 in IPC::SyncChannel::Send (this=0x6d3276f0,
message=0x6b473490) at ../../ipc/ipc_sync_channel.cc:417
#8 0x05e0da22 in ChildThread::Send (this=0x6d327784, msg=0x6b473490)
at ../../content/common/child_thread.cc:101
#9 0x05cb10f6 in RenderThreadImpl::Send (this=0x6d327780, msg=0x6b473490)
at ../../content/renderer/render_thread_impl.cc:351
#10 0x05cb5799 in RenderThreadImpl::EstablishGpuChannelSync
(this=0x6d327780,
cause_for_gpu_launch=content::CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE)
at ../../content/renderer/render_thread_impl.cc:920
#11 0x05cb5b39 in non-virtual thunk to
RenderThreadImpl::EstablishGpuChannelSync(content::CauseForGpuLaunch) ()
at ../../content/renderer/render_thread_impl.cc:960
#12 0x06031890 in WebGraphicsContext3DCommandBufferImpl::Initialize
(this=0x132e0ca0, attributes=@0xc0011170, bind_generates_resources=false,

cause=content::CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE)
at ../../content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc:184
#13 0x06124683 in
content::WebKitPlatformSupportImpl::createOffscreenGraphicsContext3D
(this=0x132489e0, attributes=@0xc0011170)
at ../../content/common/webkitplatformsupport_impl.cc:77
#14 0x024d6d1a in WebCore::GraphicsContext3D::create (attrs=
{alpha = true, depth = false, stencil = true, antialias = false,
premultipliedAlpha = true, preserveDrawingBuffer = false, noExtensions =
false, shareResources = true, preferDiscreteGPU = true},
renderStyle=WebCore::GraphicsContext3D::RenderOffscreen)
at ../../third_party/WebKit/Source/WebKit/chromium/src/GraphicsContext3DChromium.cpp:1002
#15 0x01db0b89 in WebCore::SharedGraphicsContext3DImpl::createContext
(this=0x132dc1e0)
at ../../third_party/WebKit/Source/WebCore/platform/graphics/gpu/SharedGraphicsContext3D.cpp:66
#16 0x01db0a0b in WebCore::SharedGraphicsContext3DImpl::getOrCreateContext
(this=0x132dc1e0)

at ../../third_party/WebKit/Source/WebCore/platform/graphics/gpu/SharedGraphicsContext3D.cpp:45
#17 0x01db0547 in WebCore::SharedGraphicsContext3D::get ()
at ../../third_party/WebKit/Source/WebCore/platform/graphics/gpu/SharedGraphicsContext3D.cpp:76
#18 0x01dfac6d in WebCore::createAcceleratedCanvas (size=@0x1328529c,
data=0x13282d50, deferralMode=WebCore::NonDeferred)

at ../../third_party/WebKit/Source/WebCore/platform/graphics/skia/ImageBufferSkia.cpp:99
#19 0x01dfa947 in WebCore::ImageBuffer::ImageBuffer (this=0x13282d50,
size=@0x1328529c, renderingMode=WebCore::Accelerated,
deferralMode=WebCore::NonDeferred, success=@0xc0011483)

at ../../third_party/WebKit/Source/WebCore/platform/graphics/skia/ImageBufferSkia.cpp:154

[chro...@googlecode.com]

Comment #86 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Confirmed. The --disable-gpu-switching flag resolves the issue on the
Canary for me. This would also explain why the Mac Mini with a similar ATI
GPU (but not dual-gpu) did not exhibit this problem.

[chro...@googlecode.com]

Comment #87 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Shoot.

OK, at this point there are four bugs associated with dynamic GPU
switching: this one, Issue 125416, Issue 125246, and Issue 126044. It used
to work; there's been a regression.

Brian, do you think it would be possible for you to continue to investigate
why the compositor doesn't properly detect that the context has been lost
and recover from it? Re-enable automatic graphics switching and continue to
leave gfxCardStatus disabled (or at least leave dynamic switching enabled).
This is a use case that has to work with accelerated 2D canvas and, again,
something has regressed.

I can investigate this starting next week but would really appreciate the
help at this point.

[chro...@googlecode.com]

Comment #88 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Yes, I can look into that. I have to leave the office for the day now,
though, and so might not make significant progress until next week.

[chro...@googlecode.com]

Comment #89 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Understood and thanks for investigating this to this point. Let's sync up
next Tuesday.

[chro...@googlecode.com]

Comment #90 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I used bisect-builds to attempt to find when the lost context recovery
stopped working. However, I wound up arriving at r113807 (Dec 9) which
enabled Skia on the Mac. So it seems as though the recovery never worked
correctly on aerotwist.com on this Mac.

[chro...@googlecode.com]

Updates:
Owner: k...@chromium.org

Comment #91 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I commented out all the asserts in the compositor shader setup code. What I
found from sitting in the debugger is that the compositor goes through one
frame where it's GL commands go into the black hole of a lost context.
However, at the next frame CCLayerTreeHostImpl checks if the context is
lost, finds that it is, and recreates it. So after proceeding past the
asserts that occur in the lost frame it works correctly.

I also did a Release build and I'm not reproducing the bug in that build
either. Perhaps the printfs I've added jiggered the timing around enough to
prevent a repro.

[chro...@googlecode.com]

Comment #92 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

I can reproduce the rendering problem with the web demo at
http://www.aerotwist.com/ with both Debug and Release builds. After copying
the lost context check to the beginning of
CCSingleThreadProxy::doComposite, the debug build no longer asserts, but
renders incorrectly, like the release build. It appears from examination of
a trace (attached) that re-creation of the compositor's context is
succeeding, but clearly something goes wrong during rendering. Continuing
investigation.


Attachments:
gpu_switch.trace.gz 1.4 MB

[chro...@googlecode.com]

Updates:
Status: Started

Comment #97 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #98 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Here's a reduced test case that doesn't use accelerated 2D canvas at all,
just the compositor and WebGL. It's a modified version of
LayoutTests/platform/chromium/compositing/webgl-loses-compositor-context.html
in the WebKit source tree.

It causes an assertion failure in debug Chromium builds right now, but
adding the necessary lost context checks at the beginning of the
compositor's rendering doesn't fix the rendering problem. It should render
a red square above a green one, but usually renders two red squares, or
some other incorrect content for the bottom square.

I suspect either:

- As Brian suggested, sharing between the compositor's context and the
subordinate (WebGL) context isn't working after the context loss
- The WebGL layer isn't getting properly reinitialized, and we're drawing
with a texture ID that is valid in that renderer, but is something
completely different than the WebGL output


Attachments:
webgl-loses-compositor-context.html 2.1 KB

[chro...@googlecode.com]

Comment #100 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

The fix above works; I'm preparing it for review. For the record, here's
the first assertion failure seen in debug builds before putting this fix in
place:

ERROR: Failed to create vertex shader
/Users/kbr/src/chrome.git/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/chromium/ProgramBinding.cpp(94) :
unsigned
int
WebCore::ProgramBindingBase::createShaderProgram(WebCore::GraphicsContext3D
*, const WTF::String &, const WTF::String &)
ASSERTION FAILED: m_program
/Users/kbr/src/chrome.git/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/chromium/ProgramBinding.cpp(56) :
void
WebCore::ProgramBindingBase::init(WebCore::GraphicsContext3D *, const
WTF::String &, const WTF::String &)
1 0x43db936
WebCore::ProgramBindingBase::init(WebCore::GraphicsContext3D*, WTF::String
const&, WTF::String const&)
2 0x43cf8a9 WebCore::ProgramBinding<WebCore::VertexShaderPosTexTransform,
WebCore::FragmentShaderRGBATexFlipAlpha>::ProgramBinding(WebCore::GraphicsContext3D*)
3 0x43ccde9 WebCore::ProgramBinding<WebCore::VertexShaderPosTexTransform,
WebCore::FragmentShaderRGBATexFlipAlpha>::ProgramBinding(WebCore::GraphicsContext3D*)
4 0x43c0e8c WebCore::LayerRendererChromium::textureProgramFlip()
5 0x43bb438
WebCore::LayerRendererChromium::drawTextureQuad(WebCore::CCTextureDrawQuad
const*)
6 0x43ba156 WebCore::LayerRendererChromium::drawQuad(WebCore::CCDrawQuad
const*, WebCore::FloatRect const&)
7 0x43b9cb2
WebCore::LayerRendererChromium::drawRenderPass(WebCore::CCRenderPass const*)
8 0x445e42f
WebCore::CCLayerTreeHostImpl::drawLayers(WebCore::CCLayerTreeHostImpl::FrameData
const&)
9 0x44923cb WebCore::CCSingleThreadProxy::doComposite()
10 0x449052e WebCore::CCSingleThreadProxy::commitAndComposite()
11 0x449213e WebCore::CCSingleThreadProxy::compositeImmediately()
12 0x44463f6 WebCore::CCLayerTreeHost::composite()
13 0x3966833 WebKit::WebLayerTreeView::composite()
14 0x39c04d4 WebKit::WebViewImpl::composite(bool)
15 0x771c1ed RenderWidget::DoDeferredUpdate()
16 0x77202ee RenderWidget::DoDeferredUpdateAndSendInputAck()
17 0x772202c RenderWidget::AnimationCallback()

[chro...@googlecode.com]

Comment #101 on issue 121780 by jam...@chromium.org: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

So the client side is returning 0 for program IDs in lost context case?
Seems pretty reasonable, we should make the ASSERT()s more robust. Feel
free to file a bug on me to make the program ASSERT()s more robust

[chro...@googlecode.com]

Comment #102 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Thanks, filed as https://bugs.webkit.org/show_bug.cgi?id=87912 .

[chro...@googlecode.com]

Comment #103 on issue 121780 by k...@chromium.org: 2d canvas drawImage draws
only black
http://code.google.com/p/chromium/issues/detail?id=121780

Unfortunately, the fix to WebGraphicsContext3DCommandBufferImpl's share set
doesn't solve the original problem reported here. It does, however, solve
the problems listed above with http://www.aviary.com/ and
http://www.aerotwist.com/ , as well as the problems reported in Issue
125246, Issue 125416, and Issue 126044.

Because it doesn't solve the original problem here I can't close this one
as fixed. I'm going to fix the bug under the next lowest bug ID, Issue
125246, close the others as duplicates of that one, and leave this one open
for further investigation.

[chro...@googlecode.com]

Updates:
Owner: bsalo...@google.com
Cc: natescot...@gmail.com

Comment #104 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Assigning back to myself for the original upload image issue. My suspicion
is that either the GPU process or the renderer dies on out of memory.

Nate, were you able to test the custom Chromium build I gave you?

The build had support for using GL_CHROMIUM_map_sub for large bitmap
uploads in canvas (to avoid an extra allocation) and I removed the
thumbnailer. I was only seeing the black image issue when multiple tabs
were opening repro.html and the thumbnailer was adding more shared memory
pressure for its readbacks.

[chro...@googlecode.com]

Comment #105 on issue 121780 by paul.bak...@gmail.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Just a heads up - we (Zynga) are experiencing a very similar issue (first,
a random huge texture is drawn onto the canvas, second, canvas goes black)
and are actively following this thread.

We are eager to help and happy to test out any sample builds.

[chro...@googlecode.com]

Comment #106 on issue 121780 by bugdro...@chromium.org: 2d canvas drawImage
draws only black
http://code.google.com/p/chromium/issues/detail?id=121780#c106

The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=139884

------------------------------------------------------------------------
r139884 | k...@chromium.org | Thu May 31 15:04:28 PDT 2012

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc?r1=139884&r2=139883&pathrev=139884

Upon receiving OnError callback against a context, only clear the set of
created contexts if the receiving context is live. Otherwise, it will break
sharing among more recently created contexts.

BUG=121780,125246,125416,126044
TEST=test cases from above bugs on MacBook Pro with AMD GPU running 10.7.3;
more self-contained tests will be created under other bug IDs


Review URL: https://chromiumcodereview.appspot.com/10446093
------------------------------------------------------------------------

[chro...@googlecode.com]

Updates:
Labels: merge-merged-1132

Comment #107 on issue 121780 by bugdro...@chromium.org: 2d canvas drawImage
draws only black
http://code.google.com/p/chromium/issues/detail?id=121780#c107

The following revision refers to this bug:

http://src.chromium.org/viewvc/chrome?view=rev&revision=140020

------------------------------------------------------------------------
r140020 | bsal...@google.com | Fri Jun 01 05:40:02 PDT 2012

Changed paths:
M
http://src.chromium.org/viewvc/chrome/branches/1132/src/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc?r1=140020&r2=140019&pathrev=140020

Merge 139884 - Upon receiving OnError callback against a context, only

clear the set of created contexts if the receiving context is live.
Otherwise, it will break sharing among more recently created contexts.

BUG=121780,125246,125416,126044
TEST=test cases from above bugs on MacBook Pro with AMD GPU running 10.7.3;
more self-contained tests will be created under other bug IDs


Review URL: https://chromiumcodereview.appspot.com/10446093

TBR=k...@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10467004
------------------------------------------------------------------------

[chro...@googlecode.com]

Comment #108 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Paul, the latest Canary contains a fix for Mac-specific issues that were
plaguing www.aerotwist.com and other sites. It'd be great if you could
check whether your issues still reproduce. Also, if you could point me to a
specific repro scenario I'll dive into it.

Because of some improvements that have gone in, the OOM issues seen on the
original issue posted here require multiple instances of the repro scenario
to be opened at once to exhibit a problem (at least from my testing).

[chro...@googlecode.com]

Updates:
Cc: senorbla...@chromium.org

Comment #109 on issue 121780 by senorbla...@chromium.org: 2d canvas

drawImage draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

[chro...@googlecode.com]

Comment #110 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

On the latest Canary I can only reproduce a problem with repro.html by
loading it in many (7+) tabs at once on my Mac Book Pro. The failure mode
is a OOM crash in the GPU process during texture upload. I've attached the
gpu service log. The call stack is:

base::debug::BreakDebugger () at ../../base/debug/debugger_posix.cc:216
216 _exit(1);
(gdb) bt 40
#0 base::debug::BreakDebugger () at ../../base/debug/debugger_posix.cc:216
#1 0x00e8e923 in base::(anonymous
namespace)::ScopedClearErrno::~ScopedClearErrno ()
at ../../base/process_util_mac.mm:651
#2 0x00e8e923 in base::(anonymous
namespace)::ScopedClearErrno::~ScopedClearErrno () at
/Users/bsalomon/Documents/chromium/src/base/process_util_mac.mm:558
#3 0x00e8e923 in base::(anonymous namespace)::oom_killer_malloc
(zone=0x64000, size=53011200) at ../../base/process_util_mac.mm:653
#4 0x9abf1962 in malloc_zone_malloc ()
#5 0x9abf2882 in malloc ()
#6 0x07c47f7e in gfxAllocateTextureLevel ()
#7 0x099bd177 in glTexSubImage2D_Exec ()
#8 0x07c53e5d in glTexSubImage2D ()
#9 0x00ee410e in gpu::gles2::GLES2DecoderImpl::DoTexSubImage2D
(this=<value temporarily unavailable, due to optimizations>, target=<value
temporarily unavailable, due to optimizations>, level=0, format=<value
temporarily unavailable, due to optimizations>, type=<value temporarily
unavailable, due to optimizations>, data=<value temporarily unavailable,
due to optimizations>)
at ../../gpu/command_buffer/service/gles2_cmd_decoder.cc:7344
#10 0x00ed5a80 in gpu::gles2::GLES2DecoderImpl::HandleTexSubImage2D
(this=0x64000, immediate_data_size=48152753, c=<value temporarily
unavailable, due to optimizations>)
at ../../gpu/command_buffer/service/gles2_cmd_decoder.cc:7406
#11 0x00ecb312 in gpu::gles2::GLES2DecoderImpl::DoCommand (this=0x7d04500,
command=<value temporarily unavailable, due to optimizations>,
arg_count=<value temporarily unavailable, due to optimizations>,
cmd_data=0xcc3437c)
at ../../gpu/command_buffer/service/gles2_cmd_decoder.cc:3133
#12 0x00ebb3cb in gpu::CommandParser::ProcessCommand (this=0x796c8ab0)
at ../../gpu/command_buffer/service/cmd_parser.cc:71
#13 0x00ee7e13 in gpu::GpuScheduler::PutChanged (this=0x7a2570e0)
at ../../gpu/command_buffer/service/gpu_scheduler.cc:69
#14 0x0220aa51 in base::internal::Invoker<1,
base::internal::BindState<base::internal::RunnableAdapter<void
(gpu::GpuScheduler::*)()>, void ()(gpu::GpuScheduler*), void
()(base::internal::UnretainedWrapper<gpu::GpuScheduler>)>, void
()(gpu::GpuScheduler*)>::Run (base=0x7a143860) at bind_internal.h:132
#15 0x00ebba78 in gpu::CommandBufferService::Flush (this=<value temporarily
unavailable, due to optimizations>, put_offset=<value temporarily
unavailable, due to optimizations>) at callback.h:272
#16 0x02208baa in GpuCommandBufferStub::OnAsyncFlush (this=0x7a445b60,
put_offset=<value temporarily unavailable, due to optimizations>,
flush_count=<value temporarily unavailable, due to optimizations>)
at ../../content/common/gpu/gpu_command_buffer_stub.cc:456
#17 0x02206e25 in DispatchToMethod<GpuCommandBufferStub, void
(GpuCommandBufferStub::*)(int, unsigned int), int, unsigned int> () at
/Users/bsalomon/Documents/chromium/src/base/tuple.h:366
#18 0x02206e25 in
GpuCommandBufferMsg_AsyncFlush::Dispatch<GpuCommandBufferStub,
GpuCommandBufferStub, void (GpuCommandBufferStub::*)(int, unsigned int)> ()
at
/Users/bsalomon/Documents/chromium/src/content/common/gpu/gpu_messages.h:366
#19 0x02206e25 in GpuCommandBufferStub::OnMessageReceived (this=<value
temporarily unavailable, due to optimizations>, message=<value temporarily
unavailable, due to optimizations>) at gpu_messages.h:114
#20 0x02209b6b in non-virtual thunk to
GpuCommandBufferStub::OnMessageReceived(IPC::Message const&) ()
at ../../content/common/gpu/gpu_command_buffer_stub.cc:618
#21 0x02221b50 in MessageRouter::RouteMessage (this=<value temporarily
unavailable, due to optimizations>, msg=@0x929bdc22)
at ../../content/common/message_router.cc:46

Attachments:
gpu_service_log_oom_crash.txt 2.1 MB

[chro...@googlecode.com]

Comment #111 on issue 121780 by pucchaka...@chromium.org: 2d canvas

drawImage draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Still reproducible with the build 20.0.1132.27 - Mac osx 10.7.4
GPU Card --> ATI Radeon HD 6490M

[chro...@googlecode.com]

Comment #112 on issue 121780 by paul.bak...@gmail.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Update from Zynga: With the latest Canary changes, we haven't been able to
reproduce the issue. Great job, let's hope we'll have this in stable soon!

Thanks,
Paul

[chro...@googlecode.com]

Comment #114 on issue 121780 by g...@chromium.org: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Any idea what mesa reports? Since it's software it seems like it would (or
could) have a large limit

[chro...@googlecode.com]

Comment #115 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

I believe the large texture issue of comment #113 is not Skia-related as
the 10200x6600 repro.jpg does not appear to work in a simple WebGL sample
but a version shrunk down to 8000x5176 does.

[chro...@googlecode.com]

Comment #116 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

gman@, OSMesa reports a max texture size of 4K.

[chro...@googlecode.com]

Comment #117 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

gman@ and vangelis@, I propose we artificially limit max texture size to 8K
until we can fix the large texture problem (and write tests for it). Does
that seem reasonable to you?

[chro...@googlecode.com]

Comment #118 on issue 121780 by bourier....@gmail.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Reproduceable with MacBook Pro OSX 10.7.4
AMD Radeon HD 6750M 1024 MB
with Chrome Version 19.0.1084.56

Carnary release works fine for me, thx for that.

May i guess this is a HARDWARE GPU/GFX related problem based on the AMD
Radeon Chipset, wouldn't be the first time. I also recognized
screenshotable pixel distortion in MacOSX version OSX 10.6.x with this
card, gone since update to 10.7.x.



Attachments:
distortion.png 3.4 KB

[chro...@googlecode.com]

Comment #119 on issue 121780 by bourier....@gmail.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Have made a service appointment with apple tomorrow,
will let you know ASAP, if we all need new mainboards.

[chro...@googlecode.com]

Comment #120 on issue 121780 by bourier....@gmail.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

The Apple Store (Genius) wants to send the Book in. They didn't confirm nor
denied a hardware bug. 'It seems to be a hardware Issue, but we must
check!' they said.

My private Apple Dealer (also officially licensed) offered me a direct
mainboard switch, an told me the GPU is damaged.

Will let you know ASAP when the board's successfully switched, don't thrust
them until it's finally replaced for free.

[chro...@googlecode.com]

Comment #121 on issue 121780 by jonemer...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Hey Chromium Folks - I'm from the Google+ Engineering team and I'd just
like to express my interest in your continued work fixing this bug :). We
use Chrome's canvas handling to downsample images when they're uploading,
so that users with nice digital cameras can still upload their photos
quickly. Unfortunately, a lot of people are seeing all black images, or
almost all black images, and they report these bugs to us a LOT.

BTW There's some correlation with people running out of browser memory and
this bug happening more often.

Anyway, we've much looking forward to you fixing this bug!! Thanks for
working on it!

[chro...@googlecode.com]

Comment #122 on issue 121780 by bourier....@gmail.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

Here the news, i got my mainboard replaced, exact same model, same card

- the error discussed above still persists

but

- The pixel distortion is gone for now
- the machine runs incredibly cool, about 30 cooler than before

The Engineer pointed out this may be a driver related problem. He thinks
apple will fix this with a video driver update near future.

As jonemer, he also pointed out that the problem is known and apple should
be already aware of it.

It seems that you are on the right way, doing the debug work for AMD, they
should thank you.

[chro...@googlecode.com]

Comment #123 on issue 121780 by bsalo...@google.com: 2d canvas drawImage

draws only black
http://code.google.com/p/chromium/issues/detail?id=121780

M20 is shipping imminently and has the fix for Issue 125246. Also a fix for
the large textures on recent ATI/Macs (Issue 133936) was fixed just now and
will hit Canary soon. I believe a large percentage of the repros of the
black canvas issues in the wild are caused by these issues.

[chro...@googlecode.com]

Comment #127 on issue 121780 by nicol...@taopix.com: 2d canvas drawImage
draws only black
https://code.google.com/p/chromium/issues/detail?id=121780

This is still occuring on Mac

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #128 on issue 121780 by nicolas....@gmail.com: 2d canvas drawImage

draws only black
https://code.google.com/p/chromium/issues/detail?id=121780

I ma still gettting this issue using Chrome 40.0.2214.111 on Mac

[chro...@googlecode.com]

Comment #129 on issue 121780 by nicolas....@gmail.com: 2d canvas drawImage

draws only black
https://code.google.com/p/chromium/issues/detail?id=121780

I am still gettting this issue using Chrome 40.0.2214.111 on Mac