Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-08-02 Thread Michel Dänzer
On 08.07.2016 19:01, Michel Dänzer wrote: > From: Michel Dänzer > > The unnecessary FlushCallback calls could cause significant performance > degradation with compositing. > > As an example, with the radeon driver using glamor, a gtkperf run using > default parameters

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-18 Thread Keith Packard
Adam Jackson writes: > My epoll branch has been rebased atop that as well. I've rebased a nearly identical branch atop the two poll emulation patches I just sent out in my tree. I think we're ready to merge that code to master now; it should 'just work' on mingw. -- -keith

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-18 Thread Adam Jackson
On Tue, 2016-07-12 at 09:49 -0700, Keith Packard wrote: > Adam Jackson writes: > > > Here's an epoll branch rebased to master, with poll emulation for > > Windows, and a pair of proof-of-concept patches at the end to allow > > (force) testing on pollful systems: > > So you're

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-12 Thread Keith Packard
Adam Jackson writes: > Here's an epoll branch rebased to master, with poll emulation for > Windows, and a pair of proof-of-concept patches at the end to allow > (force) testing on pollful systems: So you're just emulating poll with select, which should work on Windows. that seems

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-12 Thread Adam Jackson
On Mon, 2016-07-11 at 12:32 -0400, Peter Harris wrote: > On 2016-07-08 16:33, Keith Packard wrote: > > Adam Jackson writes: > > > > > Still not cool with committing code that we _know_ will break a > > > supported platform. > > > > Oh, right, windows. Hrm. Suggestions welcome,

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-11 Thread Keith Packard
Peter Harris writes: > The number of fds in fd_set isn't really fixed. FD_SETSIZE is user > controlled, so I can't imagine a problem with massaging fd_set into C99 > variable-length-array form: > > typedef struct xfd_set { > u_int fd_count; > SOCKET

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-11 Thread Peter Harris
On 2016-07-08 16:33, Keith Packard wrote: > Adam Jackson writes: > >> Still not cool with committing code that we _know_ will break a >> supported platform. > > Oh, right, windows. Hrm. Suggestions welcome, but I suspect the only > workable solution will be to write some

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-08 Thread Keith Packard
Adam Jackson writes: > Still not cool with committing code that we _know_ will break a > supported platform. I wasn't aware of any platform this would break? Am I missing something? -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-08 Thread Keith Packard
Adam Jackson writes: > Still not cool with committing code that we _know_ will break a > supported platform. Oh, right, windows. Hrm. Suggestions welcome, but I suspect the only workable solution will be to write some windows-specific code that does the wait for multiple objects

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-08 Thread Adam Jackson
On Fri, 2016-07-08 at 16:37 +0200, Keith Packard wrote: > Keith Packard writes: > > > It should, however, be sufficient to simply move the callback in > > FlushAllOutput after the check for 'newoutput'; newoutput should only > > ever be set if there is output to deliver. > >

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-08 Thread Keith Packard
Keith Packard writes: > It should, however, be sufficient to simply move the callback in > FlushAllOutput after the check for 'newoutput'; newoutput should only > ever be set if there is output to deliver. It'd also be awesome to get the epoll patches merged to test the

Re: [PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-08 Thread Keith Packard
Michel Dänzer writes: > From: Michel Dänzer > > The unnecessary FlushCallback calls could cause significant performance > degradation with compositing. Yeah, we do need a flush callback in drivers to ensure that damage events aren't sent without the

[PATCH xserver] FlushAllOutput: Only call FlushCallbacks when actually flushing data

2016-07-08 Thread Michel Dänzer
From: Michel Dänzer The unnecessary FlushCallback calls could cause significant performance degradation with compositing. As an example, with the radeon driver using glamor, a gtkperf run using default parameters (100 iterations of every test) takes: (numbers without =>