Mozilla/5.0 (Android; Linux armv7l; rv:2.0b10pre) Gecko/20110118 Firefox/4.0b10pre Fennec/4.0b4pre ID:20110118042354 Seen this happen on: http://m.digg.com http://pastebin.com http://news.ycombinator.com http://m.cnn.com Device: HTC Google Nexus One Prefs: layers.acceleration.disabled, false layers.accelerate-all, true
I can also see this.
It looks like R and B are swapped for some reason.
This happens on my Galaxy S too. It must have regressed in the last little bit.
Romaxa, do you think the EGL changes broke this?
hmmm.. I see it on my Galaxy Tab too.. I'll check it tomorrow.
with backing surface path it render fine, but without backing surface it swap colors also on maemo6. Here we are expecting BGRALayerProgramType always http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/GLContextProviderEGL.cpp#1029 and color swap happening because we are changing mShaderType here: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/GLContext.cpp#1358 and the rest of code seems does not care about that and some messup happening around
Looks like this was caused by the component alpha changes: // Note BGR: Cairo's image surfaces are always in what // OpenGL and our shaders consider BGR format. ColorTextureLayerProgram *basicProgram = aManager->GetBasicLayerProgram(mLayer->CanUseOpaqueSurface(), !mTexImage->IsRGB()); The comment is wrong, and my guess is that mTexImage doesn't have the right IsRGB().
sure, you right, IsRGB I guess already dead after recent changes related to mShaderType...
And reason why it works with backing surface is CreateBackingSurface mIsRGBFormat = PR_TRUE.
Created attachment 510086 [details] [diff] [review] Possible Fix I haven't actually tested this other than confirm that it compiles and doesn't horribly break anything on mac. Romaxa: Can you please check if this fixes the issue on maemo and that I haven't accidentally broken anything else in the EGL provider.
This does not seem to be happening anymore. (Testing on a Nexus S, it was fixed sometime between the nightly builds of April 8 and April 10.) Any objections to marking this Resolved?
Matt the issue doesn't seem to reproduce. Are the changes still needed?
Taking the bug so it has an owner.
This may be related to bug 661002.
Removing the IsRGB() code paths still seem worthwhile as it's been replaced by GetShaderProgramType(). I'm not sure about the other hunks, probably not if the bug no longer happens.
Created attachment 566205 [details] [diff] [review] Remove IsRGB
I think you may forgotten to qref this patch BenWa. You can definitely have an r+ in it's current form though.
Created attachment 566316 [details] [diff] [review] Remove IsRGB Opps!
Created attachment 566320 [details] [diff] [review] Remove IsRGB Sorry, trying to work on too many patches at once :(
Comment on attachment 566320 [details] [diff] [review] Remove IsRGB Review of attachment 566320 [details] [diff] [review]: ----------------------------------------------------------------- Is that assertion really the only code reading IsRGB()? r+++++