Closed
Bug 609637
Opened 14 years ago
Closed 14 years ago
Don't swapBuffers with NULL EndTransaction call
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0b3+ | --- |
People
(Reporter: romaxa, Unassigned)
References
Details
Attachments
(1 file)
658 bytes,
patch
|
cjones
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
Blocking?
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Reporter | ||
Comment 4•14 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.
Updated•14 years ago
|
blocking2.0: ? → ---
tracking-fennec: --- → 2.0b3+
Reporter | ||
Comment 5•14 years ago
|
||
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.
Description
•