GL context destroyed on every scroll started event in SurfaceBufferOGL

RESOLVED DUPLICATE of bug 592464

Status

defect
RESOLVED DUPLICATE of bug 592464
9 years ago
3 years ago

People

(Reporter: romaxa, Unassigned)

Tracking

Trunk
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

9 years ago
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
Reporter

Comment 2

9 years ago
Ok, 
tested on latest m-c: 6ec3a45f4309, and problem already fixed there.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Reporter

Comment 3

9 years ago
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 → ---
Reporter

Comment 4

9 years ago
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
Reporter

Updated

9 years ago
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.
Reporter

Comment 6

9 years ago
> 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.
Reporter

Comment 8

9 years ago
Ok, problem in bad implemented CreateTextureImage... which is creating new GLContext for each TextureImage...
Reporter

Comment 9

9 years ago
Posted patch EGL backend rework, WIP1 (obsolete) — Splinter Review
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
Reporter

Comment 10

9 years ago
Attachment #481498 - Attachment is obsolete: true
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.
Reporter

Comment 12

9 years ago
ok, then it is dup for 592464
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 592464
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.