Francisco Jerez writes:
> Francisco Jerez writes:
>
>> The current buffer validation approach (AKA the DRI2 glViewport hack)
>> is both incorrect (because a compliant OpenGL application may opt for
>> the identity as viewport transform and work with window coordinates
>> directly) and inefficien
Francisco Jerez writes:
> The current buffer validation approach (AKA the DRI2 glViewport hack)
> is both incorrect (because a compliant OpenGL application may opt for
> the identity as viewport transform and work with window coordinates
> directly) and inefficient (some programs have the habit o
Kristian Høgsberg writes:
> On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez
> wrote:
>> Kristian Høgsberg writes:
>>> No, it sounds good, I'm happy that you're looking into this. I'll
>>> have a closer look tomorrow, but what I've had in mind for this kind
>>> of thing was that we could jus
On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez wrote:
> Kristian Høgsberg writes:
>> No, it sounds good, I'm happy that you're looking into this. I'll
>> have a closer look tomorrow, but what I've had in mind for this kind
>> of thing was that we could just allocate the new buffers up front i
Kristian Høgsberg writes:
> On Sat, Jan 16, 2010 at 4:58 PM, Francisco Jerez
> wrote:
>> The current buffer validation approach (AKA the DRI2 glViewport hack)
>> is both incorrect (because a compliant OpenGL application may opt for
>> the identity as viewport transform and work with window coor
On Sat, Jan 16, 2010 at 4:58 PM, Francisco Jerez wrote:
> The current buffer validation approach (AKA the DRI2 glViewport hack)
> is both incorrect (because a compliant OpenGL application may opt for
> the identity as viewport transform and work with window coordinates
> directly) and inefficient
> How do you make sure events are ordered correctly? Say a window is
> resized and the client receives the ConfigureNotify event before us, and
> it reacts drawing on the newly exposed areas: we aren't guaranteed to
> have received our event yet, so it might end up rendered in the old
> buffers.
OK
Luca Barbieri writes:
> How about just having GLX open another connection to the X server and
> use that to receive ConfigureNotify?
> Since we are using direct rendering, we must be on the same machine,
> so it's just a unix/TCP loopback connection and should always work.
> Xlib stores the displ
Using SIGIO would be a problem in a library.
However, the kernel can be told to send an arbitrary signal (see
F_SETSIG) and glibc can allocate realtime signals with
__libc_allocate_rtsig() (pthread uses this for internal signals).
---
How about just having GLX open another connection to the X server and
use that to receive ConfigureNotify?
Since we are using direct rendering, we must be on the same machine,
so it's just a unix/TCP loopback connection and should always work.
Xlib stores the display name in _XDisplay.display_name
On Sat, Jan 16, 2010 at 10:58:28PM +0100, Francisco Jerez wrote:
> The current buffer validation approach (AKA the DRI2 glViewport hack)
> is both incorrect (because a compliant OpenGL application may opt for
> the identity as viewport transform and work with window coordinates
> directly) and inef
Hi,
Luca Barbieri writes:
> What are the advantages of the new DRI2 event over the existing
> ConfigureNotify?
> Couldn't that be used as a fallback on older servers?
ConfigureNotify is a core event, so:
* All the methods we have to catch them are nasty hacks (or at
least all the methods I c
What are the advantages of the new DRI2 event over the existing ConfigureNotify?
Couldn't that be used as a fallback on older servers?
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's bes
The current buffer validation approach (AKA the DRI2 glViewport hack)
is both incorrect (because a compliant OpenGL application may opt for
the identity as viewport transform and work with window coordinates
directly) and inefficient (some programs have the habit of calling
glViewport several times
14 matches
Mail list logo
