Michel Dänzer writes:
> I stand corrected. I was thinking of the primary output as reported by
> xrandr.
I had to actually go read the code; I had not remembered what
'RRFirstOutput' did either. Shockingly, there's a *comment* describing
what it does. What was that author thinking!
--
-keith
On 03.08.2016 14:10, Keith Packard wrote:
> Michel Dänzer writes:
>
>> This can indeed only avoid the problem by accident, since there's no
>> guarantee that the primary output is even connected.
>
> Actually, he used the RRFirstOutput function which does find something
> connected to an active
Michel Dänzer writes:
> This can indeed only avoid the problem by accident, since there's no
> guarantee that the primary output is even connected.
Actually, he used the RRFirstOutput function which does find something
connected to an active CRTC, so at least it should work as he intended?
--
Dave Airlie writes:
> So we had a bug report that epiphany was rendering slow on
> modesetting + DRI3, that I tracked down to the fact it was
> rendering offscreen to a single buffer. However due to this
> rendering being offscreen we were getting the fake crtc
> chosen by the X server as the win
From: Michel Dänzer
We were asserting that these were called before from other places, but
that isn't always the case, e.g. during server shutdown.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96951
Reported-and-Tested-by: Tod Jackson
Signed-off-by: Michel Dänzer
---
present/present
From: Michel Dänzer
Easier than dealing with it in all paths that can end up here during
server shutdown.
Signed-off-by: Michel Dänzer
---
present/present.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/present/present.c b/present/present.c
index 5fde846..8d37395 100
On 03.08.2016 09:24, Dave Airlie wrote:
> So we had a bug report that epiphany was rendering slow on
> modesetting + DRI3, that I tracked down to the fact it was
> rendering offscreen to a single buffer. However due to this
> rendering being offscreen we were getting the fake crtc
> chosen by the X
On 03.08.2016 09:40, Eric Anholt wrote:
> Keith Packard writes:
>
>> Michel Dänzer writes:
>>
>>> From: Michel Dänzer
>>>
>>> This change has two effects:
>>>
>>> 1. Only calls FlushCallbacks when we're actually flushing data to a
>>>client. The unnecessary FlushCallback calls could cause s
On 03.08.2016 09:40, Eric Anholt wrote:
> Michel Dänzer writes:
>
>> From: Michel Dänzer
>>
>> This change has two effects:
>>
>> 1. Only calls FlushCallbacks when we're actually flushing data to a
>>client. The unnecessary FlushCallback calls could cause significant
>>performance degrad
Eric Anholt writes:
> We glFlush in the BlockHandler in glamor.
Sure, what ensures that is called before damage events are delivered?
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://
Keith Packard writes:
> Michel Dänzer writes:
>
>> From: Michel Dänzer
>>
>> This change has two effects:
>>
>> 1. Only calls FlushCallbacks when we're actually flushing data to a
>>client. The unnecessary FlushCallback calls could cause significant
>>performance degradation with compos
Michel Dänzer writes:
> From: Michel Dänzer
>
> This change has two effects:
>
> 1. Only calls FlushCallbacks when we're actually flushing data to a
>client. The unnecessary FlushCallback calls could cause significant
>performance degradation with compositing, which is significantly
>
So we had a bug report that epiphany was rendering slow on
modesetting + DRI3, that I tracked down to the fact it was
rendering offscreen to a single buffer. However due to this
rendering being offscreen we were getting the fake crtc
chosen by the X server as the window didn't overlap any
active CR
The caller passes arguments into XaceCensorImage that are in window-relative
coordinates. However, the pBuf that it uses to construct a temporary pixmap has
its origin at (x, y) relative to the window in question. The code to convert the
censor region into boxes adjusts for the Y coordinate, but le
Michel Dänzer writes:
> From: Michel Dänzer
>
> This change has two effects:
>
> 1. Only calls FlushCallbacks when we're actually flushing data to a
>client. The unnecessary FlushCallback calls could cause significant
>performance degradation with compositing, which is significantly
>
On 2 August 2016 at 10:24, Olivier Fourdan wrote:
> The frame callback set up via wl_surface_frame() needs to be freed with
> wl_callback_destroy() or we'll leak memory.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97065
> Signed-off-by: Olivier Fourdan
Reviewed-by: Daniel Stone
_
The frame callback set up via wl_surface_frame() needs to be freed with
wl_callback_destroy() or we'll leak memory.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97065
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-cursor.c | 2 ++
hw/xwayland/xwayland.c| 2 ++
2 files
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 (100 iterations of every te
From: Michel Dänzer
This change has two effects:
1. Only calls FlushCallbacks when we're actually flushing data to a
client. The unnecessary FlushCallback calls could cause significant
performance degradation with compositing, which is significantly
reduced even without any driver chang
19 matches
Mail list logo
