xcb surfaces and expose events

[Theo Veenker]

Hi Steve,

On 21/06/2025 18:16, Steven J Abner wrote:
> Having a strobe/flashing issue that hoping in cairo's design you figured a way to 
> overcome. This issue occurs on x server, with or without a window manager, and configure 
> notify events are involved.
> 
> This occurs on resizing. Two cases to hopefully qualify conditions. One I have a condition 
> where resizing occurs internal to a window, cairo surfaces resized and redrawn with 
> internal configuring and invalidate areas to cause an expose event. The other, resizing a 
> window, configure notify events sent approx 1/60 sec, causing it to run through same 
> internal configure as first, but no invalidate areas causing expose knowing that the x 
> server sends one after configure notify. The strobe/flashing issue only occurs when I have 
> to involve xorg with configure notify. Both resizing speeds are at same lightening pace.
> 
> This is a single thread operation, so only one possibility I haven't tried is lock the 
> display server during 'blit' to video buffer or surface. Here is the expose event code:
> 
> bool
> _event_expose(xcb_generic_event_t *nvt) {
> 
>   xcb_expose_event_t *expose = (xcb_expose_event_t*)nvt;
>   PhxInterface *iface = ui_interface_for(expose->window);
>   cairo_t *cr;
> 
>   DEBUG_ASSERT( ( ((int16_t)expose->x < 0) || ((int16_t)expose->y < 0) ),
>                    "probable failure: _event_expose().");
> 
>   _interface_draw(iface, expose);
> 
>   cr = cairo_create(iface->vid_buffer);
>   cairo_rectangle(cr, expose->x, expose->y,
>                       expose->width, expose->height);
>   cairo_clip(cr);
>   cairo_set_source_surface(cr, iface->surface, 0, 0);
>   cairo_paint(cr);
>   DEBUG_ASSERT((cairo_status(cr) != CAIRO_STATUS_SUCCESS),
>                                 "failure: _event_expose().");
>   cairo_destroy(cr);
>   cairo_surface_flush(iface->vid_buffer);
>   return true;
> }
> 
> I have also reduced configure timer to have expose events occur very close to 1/60 sec
> which didn't appear to help. I also have not found a IN/OUT register type of call to 
> receive start of blanking from either xorg or linux. I had assumed that xorg knows when it 
> returned from it's expose, it draws surface at correct time. Assuming xorg does know, then 
> can you tell, advise, on what I'm doing wrong? Do I need to lock the server, guessing that 
> strobe/flashing occurs on my painting of vid buffer as xorg is drawing?

Drawing under X is not synced with vertical retrace. So unless you do that yourself or use 
a compositing WM it will flash. Under X you can use the drm library to wait for vblanks 
(search online for vbltest.c). Using double buffering might also help a lot.

I'm attaching a thingy I wrote to test vsync on multiple heads using drm.

> Vid buffer uses 'cairo_xcb_surface_set_size()' and drawing surfaces are only created anew 
> when a surface is altered past it's max width/height used in any sizing attempt. Uses clip 
> to draw valid surface areas. Draw surfaces drawn/painted to 'iface->surface'.
> 
> Here are the 2 case's pngs in hopes that it may help visualize what the heck this guy's 
> talking 'bout. xxhbr blue button resizes window. xxgtx frame around text/label objects 
> used as drag grip area to resize a 'pane' area. Again, this is with/without a window 
> manager. If thinking SYNC, that's for WM case only, afaict and remember, and produces odd 
> results on which one choose.

Er... what?

> 
> I'm 99.99% certain this is not due to cairo. But being it's drawing, hopes are that you 
> have encountered and worked this out before.
> Fingers crossed,
> Steve

I believe there's a compositing WM message you can request for to get informed of a vblank 
happening? I haven't yet looked into this. Unless your target plaform is X only this is 
where we're moving anyway.

-- 
Theo Veenker  |  Behavioral Experiment Systems
theo.veenker at beexy.nl  |  www.beexy.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drmtest.cpp
Type: text/x-c++src
Size: 10942 bytes
Desc: not available
URL: <https://lists.cairographics.org/archives/cairo/attachments/20250622/4f00fca3/attachment.cpp>