Closed Bug 609637 Opened 14 years ago Closed 14 years ago

Don't swapBuffers with NULL EndTransaction call

Categories

(Core :: Graphics, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
fennec 2.0b3+ ---

People

(Reporter: romaxa, Unassigned)

References

Details

Attachments

(1 file)

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.
Blocking?
blocking2.0: --- → ?
(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+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: