Don't swapBuffers with NULL EndTransaction call

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: romaxa, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(fennec2.0b3+)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Florian found that we call swapBuffers twice for basic image animation on remote page

First Swap

#0  mozilla::gl::GLContextEGL::SwapBuffers (this=0x43c45c00) at gfx/thebes/GLContextProviderEGL.cpp:749          
#1  0x3e9ad60c in mozilla::layers::LayerManagerOGL::Render (this=0x43b2ee40) at gfx/layers/opengl/LayerManagerOGL.cpp:607
#2  0x3e9ad6fc in mozilla::layers::LayerManagerOGL::EndTransaction (this=0x43b2ee40, aCallback=0, aCallbackData=0x0) at gfx/layers/opengl/LayerManagerOGL.cpp:414
#3  0x3e9bc188 in mozilla::layers::ShadowLayersParent::RecvUpdate (this=0x45053040, cset=..., reply=<value optimized out>) at gfx/layers/ipc/ShadowLayersParent.cpp:426
#4  0x3e76f050 in mozilla::layers::PLayersParent::OnMessageReceived (this=0x45053040, __msg=<value optimized out>, __reply=@0xaeadb464) at PLayersParent.cpp:220



Second Swap
#0  mozilla::gl::GLContextEGL::SwapBuffers (this=0x43c45c00) at gfx/thebes/GLContextProviderEGL.cpp:749
#1  0x3e9ad60c in mozilla::layers::LayerManagerOGL::Render (this=0x43b2ee40) at gfx/layers/opengl/LayerManagerOGL.cpp:607
#2  0x3e9ad6fc in mozilla::layers::LayerManagerOGL::EndTransaction (this=0x43b2ee40, aCallback=0x3dc3c9c0 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*)>, aCallbackData=0xaead8398)
    at gfx/layers/opengl/LayerManagerOGL.cpp:414
#3  0x3dc6d560 in nsDisplayList::PaintForFrame (this=<value optimized out>, aBuilder=0xaead8398, aCtx=<value optimized out>, aForFrame=<value optimized out>, aFlags=1) at layout/base/nsDisplayList.cpp:461
#4  0x3dc6d6f8 in nsDisplayList::PaintRoot (this=0x43c45c00, aBuilder=0x1, aCtx=0x3f04f618, aFlags=<value optimized out>) at layout/base/nsDisplayList.cpp:368
#5  0x3dc80ae8 in nsLayoutUtils::PaintFrame (aRenderingContext=<value optimized out>, aFrame=0xaead8654, aDirtyRegion=<value optimized out>, aBackstop=<value optimized out>, aFlags=4) at layout/base/nsLayoutUtils.cpp:1440
#6  0x3dc8f078 in PresShell::Paint (this=0x402ae4e0, aDisplayRoot=0x4269aa60, aViewToPaint=<value optimized out>, aWidgetToPaint=0x426b1100, aDirtyRegion=..., aIntDirtyRegion=..., aPaintDefaultBackground=0, aWillSendDidPaint=0)
    at layout/base/nsPresShell.cpp:6088
#7  0x3e077ba8 in nsViewManager::RenderViews (this=0x426a43d0, aView=0x4269aa60, aWidget=0x426b1100, aRegion=<value optimized out>, aIntRegion=..., aPaintDefaultBackground=0, aWillSendDidPaint=0) at view/src/nsViewManager.cpp:447
#8  0x3e077cb0 in nsViewManager::Refresh (this=0x426a43d0, aView=0x4269aa60, aWidget=0x426b1100, aRegion=..., aUpdateFlags=1) at view/src/nsViewManager.cpp:413
Attachment #488218 - Flags: review?(jones.chris.g)
Comment on attachment 488218 [details] [diff] [review]
No render in null transaction

"NULL callback meaning" --> "NULL callback means"
Attachment #488218 - Flags: review?(jones.chris.g) → review+
That's an odd thing to base on null callback, IMO -- what's a type of "non-painting" transaction?  At the very least this needs to be documented in the header file for EndTransaction as well.
(Reporter)

Comment 3

9 years ago
Blocking?
(Reporter)

Updated

9 years ago
blocking2.0: --- → ?
(Reporter)

Comment 4

9 years ago
(In reply to comment #3)
> Blocking?

This should be safe, and I  don't see how HW accelerated remote rendering will work without it.
blocking2.0: ? → ---
tracking-fennec: --- → 2.0b3+
(Reporter)

Comment 5

9 years ago
http://hg.mozilla.org/mozilla-central/rev/72abdd9035ec
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.