[PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

[Olivier Fourdan]

Hey,

On Thu, Apr 19, 2018 at 5:33 PM, Olivier Fourdan <ofourdan at redhat.com>
wrote:

>
> But there are still oddities, like some window remaining black for like
> 2~3 seconds after re-mapping.
>
> Closing the skypeforlinux toplevel and restoring it by running it again
> triggers the black window for a few second issue (skype doesn't really
> quit, it remains running, until it's recalled again, so this is the same
> X11 client)
>


So some quick update on those differed content update, those are caused by
dequeuing events waiting for the expected target msc.

I'm quite old school and printf() is usually my preferred approach to
investigate such issues...

On first map, everything is fine:

|  xwl_present_queue_vblank: xwl_window 0x2c258d0 target 3
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 2 msc 2
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 2 msc 2
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 3 msc 2
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 3 msc 3
|  xwl_present_queue_vblank: win 0x2c28430
|  xwl_present_queue_vblank: xwl_window 0x2c258d0 target 4
|  xwl_present_queue_vblank: win 0x2c28430
|  xwl_present_queue_vblank: xwl_window 0x2c258d0 target 5
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 4 msc 4
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 5 msc 4
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 5 msc 5
|  ...
|  xwl_present_queue_vblank: xwl_window 0x2c258d0 target 218
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 217 msc 217
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 218 msc 217
|  xwl_present_events_notify: xwl_window 0x2c258d0 target 218 msc 218

All is well, the target and msc are kept in sync, windows update occurs as
expected, with vblank and all.

Then the window is closed (thus unrealized) and shown again, and the
expected msc goes back to 1 but the target is still at its old (much
higher) value:

|  xwl_present_queue_vblank: win 0x2c28430
|  xwl_present_queue_vblank: xwl_window 0x2d3bc20 target 219
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 219 msc 2
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 219 msc 3
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 219 msc 4
|  xwl_present_queue_vblank: win 0x2c28430
|  xwl_present_queue_vblank: xwl_window 0x2d3bc20 target 220
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 219 msc 5
|  ...
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 219 msc 83
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 220 msc 83
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 219 msc 84
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 220 msc 84
|  ...
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 220 msc 219
|  xwl_present_queue_vblank: win 0x2c28430
|  xwl_present_queue_vblank: xwl_window 0x2d3bc20 target 221
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 220 msc 220
|  xwl_present_events_notify: xwl_window 0x2d3bc20 target 221 msc 220
|  xwl_present_queue_vblank: win 0x2c28430

And bam! it's showing its content when the current msc reaches the target
msc.

So basically, the more you wait before unmapping the window, the longer
you'll have to wait before its content shows up again on re-map...

Cheers,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180420/03340f9f/attachment.html>