597590 - GL context destroyed on every scroll started event in SurfaceBufferOGL

Status: RESOLVED DUPLICATE of bug 592464

(Core Graveyard :: Widget: Qt, defect)

Description

[Oleg Romashin (:romaxa)]

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

Comment 1

[Oleg Romashin (:romaxa)]

Attachment: backtrace on destroy gl context log

Comment 2

[Oleg Romashin (:romaxa)]

Ok, 
tested on latest m-c: 6ec3a45f4309, and problem already fixed there.

Comment 3

[Oleg Romashin (:romaxa)]

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.

Comment 4

[Oleg Romashin (:romaxa)]

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

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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.

Comment 6

[Oleg Romashin (:romaxa)]

> 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.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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.

Comment 8

[Oleg Romashin (:romaxa)]

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

Comment 9

[Oleg Romashin (:romaxa)]

Attachment: EGL backend rework, WIP1

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

Comment 10

[Oleg Romashin (:romaxa)]

Attachment: Fixed GetBackingSurface function

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 12

[Oleg Romashin (:romaxa)]

ok, then it is dup for 592464