On Tue, 2011-05-17 at 15:03 +0200, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
This should be just as good on average but is less expensive.
If we're not hitting the cache, isn't the cost of rand() pretty much
noise? On my system, rand() seems to take about 10ns.
The nice
On Tue, 2011-05-17 at 18:32 +0200, Michel Dänzer wrote:
On Die, 2011-05-17 at 11:53 -0400, Owen Taylor wrote:
On Tue, 2011-05-17 at 15:03 +0200, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
This should be just as good on average but is less expensive.
If we're
On Thu, 2010-12-02 at 09:40 -0800, James Jones wrote:
As I mentioned early on, I really want to get the fence sync work in server
1.10. The server code was reviewed by Adam Jackson (thanks for sifting
through all that) and various nvidians, but I still haven't received any
external
On Fri, 2010-12-03 at 10:13 -0800, James Jones wrote:
I wrote a slide deck on synchronization and presentation ideas for X a year
ago or so before starting this work:
http://people.freedesktop.org/~aplattner/x-presentation-and-
synchronization.pdf
Aaron presented it at XDevConf last
On Fri, 2010-12-03 at 13:08 -0800, James Jones wrote:
On Friday 03 December 2010 11:16:43 am Owen Taylor wrote:
On Fri, 2010-12-03 at 10:13 -0800, James Jones wrote:
I wrote a slide deck on synchronization and presentation ideas for X a
year ago or so before starting this work
Reviewed-by: Owen Taylor otay...@fishsoup.net
This looks good to me - it look like it is sufficient to meet the need
of making easy-to-hit hot corners on a multi-head displays with a good
amount of flexibility but without adding a lot of unmotivated
complexity.
Creating barriers relative to any
On Mon, 2010-12-06 at 09:41 -0500, Adam Jackson wrote:
On Mon, 2010-12-06 at 06:27 -0500, Owen Taylor wrote:
Reviewed-by: Owen Taylor otay...@fishsoup.net
This looks good to me - it look like it is sufficient to meet the need
of making easy-to-hit hot corners on a multi-head displays
On Tue, 2010-12-07 at 16:54 -0800, James Jones wrote:
[ In terms of GNOME 3 and NVIDIA: If it's *that* slow to update clip lists
for a GLX window, then just save the last one you got, and during
ValidateTree memcmp() and if nothing changed, don't do anything. Can't be
more than 20 lines
On Sun, 2010-05-02 at 17:57 -0700, Kristian Høgsberg wrote:
Here's a pull request for the four patches I sent out earlier. The
dix resource patch has been updated to also update the element count
for FreeClientNeverRetainResources() and FreeClientResources(), which
also didn't keep the count
that plus an application that was doing something pretty unusual
with the composite extension.
Would be definitely good to get Keith to check this as well if possible.
- Owen
Reviewed-by: Owen Taylor otay...@fishsoup.net
___
xorg-devel@lists.x.org
On Wed, 2011-07-20 at 02:54 +0300, Ville Syrjälä wrote:
BTW I noticed afterwards that this doesn't help all apps. Evince, for
example, still blinks whenever I bring up the popup menu while in
fullscreen mode, whereas Firefox doesn't blink. I did some quick
protocol tracing and I saw some
On Wed, 2011-07-20 at 10:44 -0400, Owen Taylor wrote:
On Wed, 2011-07-20 at 02:54 +0300, Ville Syrjälä wrote:
BTW I noticed afterwards that this doesn't help all apps. Evince, for
example, still blinks whenever I bring up the popup menu while in
fullscreen mode, whereas Firefox doesn't
On Thu, 2011-07-21 at 00:24 +0300, Ville Syrjälä wrote:
I did actually have to see it live to figure out what was going on ...
but once I saw it, and thought about it a bit, I was able to avoid
digging out the debugger.
What's going on is that for a window with a non-None background,
On Mon, 2011-07-25 at 20:36 +0200, Marko Macek wrote:
Sometime in the previous decade I sent patches to Mozilla to always set
window background
to None (mozilla bug 28003). Hopefully none of it got lost since then.
Mozilla has used background none as long as I can remember. I guess
since
Uli Schlachter wrote:
unsigned long XNextRequest(Display *dpy)
{
+unsigned long next_request;
+LockDisplay(dpy);
+next_request = _XNextRequest(dpy);
+UnlockDisplay(dpy);
+
return (NextRequest(dpy));
Unused variable next_request. Did you really mean to
Jasper St. Pierre wrote:
int touchid,
LockDisplay(dpy);
if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
return (NoSuchExtension);
-
- status = _XIAllowEvents(dpy, deviceid, event_mode, CurrentTime, touchid,
grab_window);
-
UnlockDisplay(dpy);
- SyncHandle();
- return status;
+
Sorry for joining the discussion late here. I went through the specs and
discussion and have various comments and questions.
- Owen
* It would be great if we could figure out a plan to get to the
point where the exact same application code is going to work for
proprietary and open source
A complex scheme where the compositor and the server collaborate on the
implementation of SwapRegion seems fragile to me, and still doesn't get
some details right - like the swap count returned from SwapRegion.
What if we made SwapRegion redirectable along the lines of
ResizeRedirectMask? Since
On Thu, 2013-02-28 at 16:55 -0800, Keith Packard wrote:
* It would be great if we could figure out a plan to get to the
point where the exact same application code is going to work for
proprietary and open source drivers. When you get down to the details
of swap this isn't close to
On Sat, 2014-12-13 at 00:32 -0800, Keith Packard wrote:
Here's a short patch series which reduces lag when using PresentPixmap
with a compositing manager. I wrote up a short description on my blog:
http://keithp.com/blogs/present-compositor/
The basic idea is to perform the CopyArea
On Mon, 2015-01-26 at 16:22 -0800, Keith Packard wrote:
Owen Taylor otay...@redhat.com writes:
Sorry for getting to this so slowly. At least for the algorithms that
GNOME currently uses, this isn't going to help avoid the extra frame of
latency.
Maybe you don't quite understand
Paalanen <ppaala...@gmail.com> wrote:
> On Wed, 30 Nov 2016 15:12:54 -0500
> Owen Taylor <otay...@fishsoup.net> wrote:
>
> > Hi Pekka,
> >
> > I don't have a lot of of commentary to add here. Certainly getting the
> > frame-sync protocols ri
Hi Pekka,
I don't have a lot of of commentary to add here. Certainly getting the
frame-sync protocols right does require integration between Xwayland and
the compositing manager. I don't think there's that much virtue in spending
time on the extended version of the sync protocol and
GTK+ is already using Xlib at a pretty low level - see gdk/x11/gdkasync.c.
So just, say, copy what
https://cgit.freedesktop.org/xorg/lib/libX11/tree/src/GetIFocus.c does
and check the return value of _XReply() - if it's 0, then you got a
BadAccess. (Or some other call if GetInputFocus doesn't do
24 matches
Mail list logo
