On Tue, 2 Feb 2016 21:06:33 +0100
Rui Matos wrote:
> If the wayland compositor hides our cursor surface (e.g. because the
> pointer moved over a different wayland client) before our last
> submitted buffer gets a chance to be displayed, no frame event will be
> sent and thus we end up in a state
All callers of SetWindowPixmap will themselves be traversing the Window
heirachy updating the backing Pixmap of each child and so we can forgo
doing the identical traversal inside the DRI2SetWindowPixmap handler.
Reported-by: Loïc Yhuel
Link: http://lists.x.org/archives/xorg-devel/2015-February/0
This workarounds issues in mesa and Mali that likes to create a new
DRI2Drawble per context and per frame, respectively. The idea is that we
only create one unnamed reference per Client on each Drawable that is
never destroyed - and we make the assumption that the only caller is
the DRI2 dispatcher
In order to ease resource tracking, disentangle DRI2Drawable XIDs from
their references. This will be used in later patches to first limit the
object leak from unnamed references created on behalf of Clients and
then never destroy, and then to allow Clients to explicit manage their
references to DR
If the Window is destroyed by another client, such as the window
manager, the original client may be blocked by DRI2 awaiting a vblank
event. When this happens, DRI2DrawableGone forgets to unblock that
client and so the wait never completes.
Note Present/xshmfence is also suspectible to this race.
Adam Jackson writes:
> I suspect this code predates the common resource hooks for computing
> sizes. It's ugly in any case since the Resource extension shouldn't
> need to know which extensions can take a reference on pixmaps. Instead,
> let's just walk every resource for the client and sum up
On Wed, Feb 03, 2016 at 09:54:43AM +, Chris Wilson wrote:
> All callers of SetWindowPixmap will themselves be traversing the Window
> heirachy updating the backing Pixmap of each child and so we can forgo
> doing the identical traversal inside the DRI2SetWindowPixmap handler.
>
> Reported-by:
On Wed, Feb 03, 2016 at 09:54:46AM +, Chris Wilson wrote:
> If the Window is destroyed by another client, such as the window
> manager, the original client may be blocked by DRI2 awaiting a vblank
> event. When this happens, DRI2DrawableGone forgets to unblock that
> client and so the wait neve
On Wed, 2016-02-03 at 21:34 +1100, Keith Packard wrote:
> Adam Jackson writes:
>
> > I suspect this code predates the common resource hooks for computing
> > sizes. It's ugly in any case since the Resource extension shouldn't
> > need to know which extensions can take a reference on pixmaps. In
The last cursor frame we commited before the pointer left one of our
surfaces might not have been shown. In that case we'll have a cursor
surface frame callback pending which we need to clear so that we can
continue submitting new cursor frames.
Signed-off-by: Rui Matos
---
On Wed, Feb 3, 2016 a
On Wed, Feb 03, 2016 at 09:54:45AM +, Chris Wilson wrote:
> This workarounds issues in mesa and Mali that likes to create a new
> DRI2Drawble per context and per frame, respectively. The idea is that we
> only create one unnamed reference per Client on each Drawable that is
> never destroyed -
On Wed, Feb 03, 2016 at 09:54:44AM +, Chris Wilson wrote:
> In order to ease resource tracking, disentangle DRI2Drawable XIDs from
> their references. This will be used in later patches to first limit the
> object leak from unnamed references created on behalf of Clients and
> then never destro
Adam Jackson writes:
> I don't really understand your objection about pixmaps not in the
> resdb, because ResQueryClientPixmapBytes is _already_ not accounting
> for those, and it's not clear to me how it even could.
Sorry, that code has gotten a lot more sophisticated since I wrote
it...
Looks
On Wed, Feb 03, 2016 at 05:46:35PM -0800, Bryce Harrington wrote:
> On Wed, Feb 03, 2016 at 04:14:09PM +0100, Rui Matos wrote:
> > The last cursor frame we commited before the pointer left one of our
> > surfaces might not have been shown. In that case we'll have a cursor
> > surface frame callback
On Wed, Feb 03, 2016 at 04:14:09PM +0100, Rui Matos wrote:
> The last cursor frame we commited before the pointer left one of our
> surfaces might not have been shown. In that case we'll have a cursor
> surface frame callback pending which we need to clear so that we can
> continue submitting new c
15 matches
Mail list logo