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
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
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
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
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,
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
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
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
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
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.
>
>
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
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
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 =>
13 matches
Mail list logo