run MOZ_QT_GRAPHICSSYSTEM=native MOZ_ACCELERATED=1 ./fennec -graphicssystem native -url about:license in console you will see : XXX stub Initializing context 0x4a522ca0 surface 0x4a9b3000 on display 0x2 Destroying context 0x4a953f70 surface 0x4c6e4c00 on display 0x2 XXX stub .... Initializing context 0x4a953f70 surface 0x4c6e4c00 on display 0x2 Destroying context 0x4a522ca0 surface 0x4a9b3000 on display 0x2 XXX stub while scrolling. Something wrong here
Ok, tested on latest m-c: 6ec3a45f4309, and problem already fixed there.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
hm... no I was running without arg flags, and CreateOffscreenSurface was creating Image surface instead of X.... (because of raster is default system.) problem still reproducible if -graphicssystem native cmd arguments provided.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Ok, we have currently 2 different paths: 1) BasicBufferOGL, which is creating ImageSurface and has own ::BeginPaint implementation. and that implementation recycle existing buffer. 2) SurfaceBufferOGL, which is using ThebesLayerBuffer::BeginPaint implementation... Problem of ThebesLayerBuffer::BeginPaint implemetation is that it is always create new Buffer when we start new scrolling, and this is bad: a) for non-accelerated fennec, because we re-create new buffer and allocate new memory on each scroll start b) for accelerated fennec it is re-creating all the time Pixmap surface and rebounding textures.... I think we should use the same BeginPaint implementation in all cases, and have it universally optimized for GL and NON-GL rendering
Summary: GL context destroyed on every scroll finished event in Qt port → GL context destroyed on every scroll started event in SurfaceBufferOGL
> Problem of ThebesLayerBuffer::BeginPaint implemetation is that it is always > create new Buffer when we start new scrolling What do you mean? ThebesLayerBuffer::BeginPaint tries to reuse the same buffer when scrolling.
> What do you mean? ThebesLayerBuffer::BeginPaint tries to reuse the same buffer > when scrolling. It does, but it always create new similar surface when user start new scrolling (from static state) I found that vlad's patch from bug 596784, make situation a bit better, I think we should have one scroll/buffer update logic for optimized and non-optimized GL path.
Depends on: 596784
(In reply to comment #6) > It does, but it always create new similar surface when user start new scrolling > (from static state) When you scroll the viewport of the toplevel content document we should not be creating new surfaces. Is that what you're testing? If you're scrolling an overflow:auto element, you will see that. That is nsGfxScrollFrame switching from "inactive" to "active" scrolling.
Ok, problem in bad implemented CreateTextureImage... which is creating new GLContext for each TextureImage...
Implement common rendering path for EGL backend, make it works using slow GL Text2DImage upload. Also added support for BackingSurface and basic BindText Image. Still not clear for canvas context
We're still using a heavyweight thing (a GL context) when we just want a lightweight texture binding from a pixmap. We need to just implement -that-, in gfxXlibSurface, in conjunction with whatever support is needed in the EGL backend to call the EGL functions for binding such a texture for drawing.
ok, then it is dup for 592464
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago → 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 592464
You need to log in before you can comment on or make changes to this bug.