<ajax>
i hate to be a stickler about this kind of thing but i don't think vulkan actually makes any promises that the swapchain image is unchanged between when you present it and next you acquire it
<zmike>
cc jekstrand
<zmike>
and bnieuwenhuizen
<ajax>
yeah, we don't even wire up the vtable slot. was that just copypasta to get the extn list to match what pre-kopper had?
<zmike>
probably
<zmike>
I was filling them in as I went
<ajax>
well the easy way to make those fails go away is to not lie about being able to do them, but probably we want it to actually work too
<ajax>
which: may be tricky
<jekstrand>
ajax: IDK that it does.
<jekstrand>
ajax: I mean, we might be able to ammend the spec so that it does but I don't know for sure.
<ajax>
i could also really use a "please mister display server release that last image back to me, allocate and blit if you have to replace it" extension
<ajax>
assuming i can actually get the above immutability promises
<ajax>
although. the "pixel ownership test" exists for exactly this reason, the display server may in fact not be able to or want to guarantee that those pixels didn't change
<jekstrand>
Vulkan swapchains do have damage rects
<jekstrand>
But that doesn't mean you can make assumptions
<ajax>
which... sounds like i want an extension to AcquireNextImage that lets the winsys feed me back whether it was dirtied
<ajax>
and maybe where?
<jekstrand>
That doesn't sound too crazy
<ajax>
can i please go one week without needing to refer to presentproto.txt
<jekstrand>
ajax: I seem to manage to. :P
<ajax>
present doesn't have enough mojo to do dirty rect return, sigh
<ajax>
and i'm not entirely sure i could bend damage to the task because we're not actually allowed to use non-xge events in libraries, good work team