[cairo] trouble with GL and GLES surfaces

[Theo Veenker]

Hi all,

I decided to spend some time on playing with cairo's GL backend. First I looked at 1.15.11
(this is all under Linux Mint 18 64-bit, kernel 4.4.0-98, X.Org 1.18.4).

Cairo 1.15.11 configured with --enable-gl worked for me. I could use
cairo_gl_surface_create_for_window(), cairo_gl_surface_create() and
cairo_surface_create_similar() as advertised.

However when configured with --enable-glesv2 I ran into some problems:
- Cairo_gl_surface_create_for_egl() is fine, but both cairo_gl_surface_create() and
cairo_surface_create_similar() consistently fail with CAIRO_STATUS_DEVICE_ERROR.
- Copying a (any) surface using cairo_paint() into a surface created by
cairo_gl_surface_create_for_egl() causes a core dump. That is, at first it sometimes looks
OK. And then when I trigger a redraw it segfaults. This does not happen with 1.14.12.
Valgrind consistently shows it is accessing location 0xC. Here's a snippit of the valgrind
log:
==24122== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==24122== Access not within mapped region at address 0xC
==24122== at 0x5AF0562: _cairo_gl_pattern_texture_setup (cairo-gl-operand.c:292)
==24122== by 0x5AF0562: _cairo_gl_operand_init (cairo-gl-operand.c:555)
==24122== by 0x5AEC03F: _cairo_gl_composite_set_source (cairo-gl-composite.c:150)
==24122== by 0x5AEC03F: _blit_texture_to_renderbuffer (cairo-gl-composite.c:108)
==24122== by 0x5AEC1BC: _cairo_gl_composite_init (cairo-gl-composite.c:1278)
==24122== by 0x5AF3B43: copy_boxes.part.0 (cairo-gl-spans-compositor.c:342)
==24122== by 0x5A9FDBC: upload_boxes (cairo-spans-compositor.c:518)
==24122== by 0x5A9FDBC: composite_aligned_boxes (cairo-spans-compositor.c:630)
==24122== by 0x5A9FDBC: clip_and_composite_boxes.part.11 (cairo-spans-compositor.c:882)
==24122== by 0x5A9FE7D: clip_and_composite_boxes (cairo-spans-compositor.c:901)
==24122== by 0x5AA0198: _cairo_spans_compositor_mask (cairo-spans-compositor.c:999)
==24122== by 0x5A57578: _cairo_compositor_paint (cairo-compositor.c:65)
==24122== by 0x5AABAF0: _cairo_surface_paint (cairo-surface.c:2198)
==24122== by 0x5AF6108: _cairo_gl_surface_draw_image (cairo-gl-surface.c:1049)
==24122== by 0x5AF39FA: draw_image_boxes (cairo-gl-spans-compositor.c:311)
==24122== by 0x5A9FDEF: upload_boxes (cairo-spans-compositor.c:514)
==24122== by 0x5A9FDEF: composite_aligned_boxes (cairo-spans-compositor.c:630)
==24122== by 0x5A9FDEF: clip_and_composite_boxes.part.11 (cairo-spans-compositor.c:882)



Then I tried the same thing using cairo 1.14.2. Here I don't see any of the problems
mentioned above. However I did notice a different problem with the regular GL (non-GLES)
backend:
- It appears I can't use a GL surface (as created by cairo_gl_surface_create() or
cairo_surface_create_similar()) as a source for cairo_set_source_surface(). No error is
reported by cairo_set_source_surface() or cairo_paint(). This does however work correctly
when configured with --enable-glesv2.


I did not test the GLESv3 backend as I have no idea where to get the glesv3 package
referred to by cairo.pc.

Theo

[Bryce Harrington]

Post by Theo Veenker
Hi all,
I decided to spend some time on playing with cairo's GL backend. First I
looked at 1.15.11 (this is all under Linux Mint 18 64-bit, kernel 4.4.0-98,
X.Org 1.18.4).

Thanks for testing the gles code.

Post by Theo Veenker
Cairo 1.15.11 configured with --enable-gl worked for me. I could use
cairo_gl_surface_create_for_window(), cairo_gl_surface_create() and
cairo_surface_create_similar() as advertised.
- Cairo_gl_surface_create_for_egl() is fine, but both
cairo_gl_surface_create() and cairo_surface_create_similar() consistently
fail with CAIRO_STATUS_DEVICE_ERROR.

Unfortunately CAIRO_STATUS_DEVICE_ERROR is used as kind of a generic
"something's wrong" error message. Could be anything from a driver
issue on up. I wouldn't rule out some flaw in my patch, either,
although if you're seeing problems creating gl surfaces on 1.14 too,
then might be a deeper issue.

I verified glesv2 worked and generated graphics for me identically
between 1.14 and 1.15 before landing, although it's possible you're
setting up the surfaces in a different way that I didn't test. If you
can give me the snippet of code you're using to set things up, or a
minimal test case or somesuch, I can examine it compared with my own and
see if I can see the same issue as you and maybe isolate why.

Post by Theo Veenker
- Copying a (any) surface using cairo_paint() into a surface created by
cairo_gl_surface_create_for_egl() causes a core dump. That is, at first it
sometimes looks OK. And then when I trigger a redraw it segfaults. This does
not happen with 1.14.12. Valgrind consistently shows it is accessing
==24122== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==24122== Access not within mapped region at address 0xC
==24122== at 0x5AF0562: _cairo_gl_pattern_texture_setup (cairo-gl-operand.c:292)

This appears to correspond with this chunk of code:

surface = (cairo_gl_surface_t *)
_cairo_gl_surface_create_scratch (ctx,
CAIRO_CONTENT_COLOR_ALPHA,
extents->width,
extents->extents->height);

Which is basically just a wrapper around _create_scratch_internal, that
calls _cairo_gl_surface_create_scratch_for_texture and then
glTexImage2D. Hard to make any guesses from there. A full backtrace
with debug symbols compiled in might give more useful information.

"address 0xC" sounds like an invalid pointer, either uninitialized
memory or an incorrect assignment or something.

Post by Theo Veenker
==24122== by 0x5AF0562: _cairo_gl_operand_init (cairo-gl-operand.c:555)
==24122== by 0x5AEC03F: _cairo_gl_composite_set_source (cairo-gl-composite.c:150)
==24122== by 0x5AEC03F: _blit_texture_to_renderbuffer (cairo-gl-composite.c:108)
==24122== by 0x5AEC1BC: _cairo_gl_composite_init (cairo-gl-composite.c:1278)
==24122== by 0x5AF3B43: copy_boxes.part.0 (cairo-gl-spans-compositor.c:342)
==24122== by 0x5A9FDBC: upload_boxes (cairo-spans-compositor.c:518)
==24122== by 0x5A9FDBC: composite_aligned_boxes (cairo-spans-compositor.c:630)
==24122== by 0x5A9FDBC: clip_and_composite_boxes.part.11 (cairo-spans-compositor.c:882)
==24122== by 0x5A9FE7D: clip_and_composite_boxes (cairo-spans-compositor.c:901)
==24122== by 0x5AA0198: _cairo_spans_compositor_mask (cairo-spans-compositor.c:999)
==24122== by 0x5A57578: _cairo_compositor_paint (cairo-compositor.c:65)
==24122== by 0x5AABAF0: _cairo_surface_paint (cairo-surface.c:2198)
==24122== by 0x5AF6108: _cairo_gl_surface_draw_image (cairo-gl-surface.c:1049)
==24122== by 0x5AF39FA: draw_image_boxes (cairo-gl-spans-compositor.c:311)
==24122== by 0x5A9FDEF: upload_boxes (cairo-spans-compositor.c:514)
==24122== by 0x5A9FDEF: composite_aligned_boxes (cairo-spans-compositor.c:630)
==24122== by 0x5A9FDEF: clip_and_composite_boxes.part.11 (cairo-spans-compositor.c:882)
Then I tried the same thing using cairo 1.14.2. Here I don't see any of the
problems mentioned above. However I did notice a different problem with the
- It appears I can't use a GL surface (as created by
cairo_gl_surface_create() or cairo_surface_create_similar()) as a source for
cairo_set_source_surface(). No error is reported by
cairo_set_source_surface() or cairo_paint(). This does however work
correctly when configured with --enable-glesv2.

As far as I know that *should* work. Is there a possibility that
there's an error in your setup code? That could explain a lot of the
problems you've described. Again, if you can send me a sample
reproducer I can take a deeper look. If it does turn out to be a
regression in the new code, your example could help me isolate it and
improve my own tests to cover that case.

Post by Theo Veenker
I did not test the GLESv3 backend as I have no idea where to get the glesv3
package referred to by cairo.pc.

The glesv3 support may be installed with glesv2. You can look in
/usr/include and /usr/lib to see if the gles 3 stuff is there, or just
try --enable-glesv3. I doubt it'll make a difference for your problem
though, but might be broken in a more interesting way.

Bryce

Post by Theo Veenker
Theo
--
Theo Veenker | Beexy - Behavioral Experiment Software
[phone] | [phone] mobile
--
cairo mailing list
https://lists.cairographics.org/mailman/listinfo/cairo

[Theo Veenker]

Post by Bryce Harrington

Post by Theo Veenker
Hi all,
I decided to spend some time on playing with cairo's GL backend. First I
looked at 1.15.11 (this is all under Linux Mint 18 64-bit, kernel 4.4.0-98,
X.Org 1.18.4).

Thanks for testing the gles code.

Post by Theo Veenker
Cairo 1.15.11 configured with --enable-gl worked for me. I could use
cairo_gl_surface_create_for_window(), cairo_gl_surface_create() and
cairo_surface_create_similar() as advertised.
- Cairo_gl_surface_create_for_egl() is fine, but both
cairo_gl_surface_create() and cairo_surface_create_similar() consistently
fail with CAIRO_STATUS_DEVICE_ERROR.

Unfortunately CAIRO_STATUS_DEVICE_ERROR is used as kind of a generic
"something's wrong" error message. Could be anything from a driver
issue on up. I wouldn't rule out some flaw in my patch, either,
although if you're seeing problems creating gl surfaces on 1.14 too,
then might be a deeper issue.
I verified glesv2 worked and generated graphics for me identically
between 1.14 and 1.15 before landing, although it's possible you're
setting up the surfaces in a different way that I didn't test. If you
can give me the snippet of code you're using to set things up, or a
minimal test case or somesuch, I can examine it compared with my own and
see if I can see the same issue as you and maybe isolate why.

I have cooked up a few test programs. Tested on two platforms (one with Radeon HD 5670 and
one with an Intel something). I get same results on both platforms. I'll send the test
code with a readme to you, so you can check it yourself.

Post by Bryce Harrington

Post by Theo Veenker
Then I tried the same thing using cairo 1.14.2. Here I don't see any of the
problems mentioned above. However I did notice a different problem with the
- It appears I can't use a GL surface (as created by
cairo_gl_surface_create() or cairo_surface_create_similar()) as a source for
cairo_set_source_surface(). No error is reported by
cairo_set_source_surface() or cairo_paint(). This does however work
correctly when configured with --enable-glesv2.

As far as I know that *should* work. Is there a possibility that
there's an error in your setup code? That could explain a lot of the
problems you've described. Again, if you can send me a sample
reproducer I can take a deeper look. If it does turn out to be a
regression in the new code, your example could help me isolate it and
improve my own tests to cover that case.

I don't know what I could be doing wrong. I'm only swapping one function call for a
similar one. For 1.15 this works, for 1.14 it does not (tested on both platforms). The
only thing I can think of is waiting until the window is fully mapped before creating GL
surfaces on it. Not tried. Don't know if it makes sense.

Post by Bryce Harrington

Post by Theo Veenker
I did not test the GLESv3 backend as I have no idea where to get the glesv3
package referred to by cairo.pc.

The glesv3 support may be installed with glesv2. You can look in
/usr/include and /usr/lib to see if the gles 3 stuff is there, or just
try --enable-glesv3. I doubt it'll make a difference for your problem
though, but might be broken in a more interesting way.

Aha. So the GLESv3 code if any is included in libGLESv2.so? I do appear to have the GLES3
headers. Maybe the glesv3 reference in cairo.pc should be dropped then? Otherwise
"pkg-config --cflags/libs cairo" commands will unnecessarily fail if no glesv3 package can
be found. Does it even exist ATM?

Theo