This problem is nagging me since a long time but recently I could better
nail it down to be a compositing problem on X11. Imagine the following
situation:
You have a window with an OpenGL context for 3D rendering.
You create the window with XCreateWindow and an OpenGL infused visual
(glXChooseVisu
On 01/08/2014 02:28 AM, Michel Dänzer wrote:
> On Mit, 2014-01-08 at 01:14 +0100, Roland Plüss wrote:
>> Is reparenting with compositing a huge problem by itself?
> Seems to work just fine for me. Which driver stack are you using? Maybe
> post your Xorg.0.log file and/or test a
On 01/08/2014 04:50 AM, Thomas Lübking wrote:
> On Mittwoch, 8. Januar 2014 01:14:20 CEST, Roland Plüss wrote:
>
>> You have a window with an OpenGL context for 3D rendering.
>> You create the window with XCreateWindow and an OpenGL infused visual
>> (glXChooseVisual).
On 01/09/2014 02:01 AM, Thomas Lübking wrote:
> On Mittwoch, 8. Januar 2014 12:20:24 CEST, Roland Plüss wrote:
>
>> xwininfo: Window id: 0x561 (has no name)
>> Depth: 24
>> Visual: 0x23
>> Visual Class: TrueColor
>> Class: InputOutput
>>
On 01/09/2014 02:31 AM, Michel Dänzer wrote:
> On Mit, 2014-01-08 at 11:50 +0100, Roland Plüss wrote:
>> On 01/08/2014 02:28 AM, Michel Dänzer wrote:
>>> On Mit, 2014-01-08 at 01:14 +0100, Roland Plüss wrote:
>>>> Is reparenting with compositing a huge problem by
On 01/09/2014 04:01 AM, Michel Dänzer wrote:
> On Don, 2014-01-09 at 03:23 +0100, Roland Plüss wrote:
>> On 01/09/2014 02:31 AM, Michel Dänzer wrote:
>>> On Mit, 2014-01-08 at 11:50 +0100, Roland Plüss wrote:
>>>> On 01/08/2014 02:28 AM, Michel Dänzer wrote:
>
On 01/09/2014 07:59 AM, Thomas Lübking wrote:
> On Donnerstag, 9. Januar 2014 02:29:59 CEST, Roland Plüss wrote:
>> It looks thus as if the GL rendering output area lags behind the window
>> position/size change as if the Compositor does apply the X event to the
>> X wi
On 01/09/2014 02:01 AM, Thomas Lübking wrote:
> On Mittwoch, 8. Januar 2014 12:20:24 CEST, Roland Plüss wrote:
>
>> xwininfo: Window id: 0x561 (has no name)
>> Depth: 24
>> Visual: 0x23
>> Visual Class: TrueColor
>> Class: InputOutput
>>
On 01/10/2014 02:09 AM, Michel Dänzer wrote:
> On Don, 2014-01-09 at 13:20 +0100, Roland Plüss wrote:
>> On 01/09/2014 04:01 AM, Michel Dänzer wrote:
>>>> How exactly could DRI2 make a problem with the cat driver?
>>> DRI2 is not the problem, it's a po
On 01/10/2014 03:01 AM, Michel Dänzer wrote:
> On Fre, 2014-01-10 at 02:31 +0100, Roland Plüss wrote:
>> On 01/10/2014 02:09 AM, Michel Dänzer wrote:
>>> On Don, 2014-01-09 at 13:20 +0100, Roland Plüss wrote:
>>>> On 01/09/2014 04:01 AM, Michel Dänzer wrote:
>&g
The special situation is this:
- A toolkit driven application (FOX-ToolKit in this case)
- Render window is "injected" into the framework (so this means no
influence to X11 event loop handling of the application)
- Main Thread: Does everything not touching OpenGL (in particular has no
GL context as
I'm finishing up my software for releasing but run into a big issue. If
I use window mode instead of full-screen mode the user should be able to
close the window using the X button. I can prevent this from happening
using this code:
Atom delAtom = XInternAtom( display, "WM_DELETE_WINDOW", False );
"display", and in your loop, you specify "pDisplay" ; is it the same
> display ?
>
> Le 19/01/2020 à 13:33, Roland Plüss a écrit :
>> I'm finishing up my software for releasing but run into a big issue. If
>> I use window mode instead of full-screen mode the
ons like gain/loose focus of
the window but not the ClientMessage. I can change who sets these window
manager hints but I would like to understand why some stuff should work
and not the other.
On 1/19/20 3:53 PM, Lucien Gentis wrote:
>
>
> Le 19/01/2020 à 15:17, Roland Plüss a écrit :
>&
wrote:
>
>
> Le 19/01/2020 à 15:17, Roland Plüss a écrit :
>>
>> Hi Lucien,
>>
>> Depends what you call the same display. The window is created in the
>> render thread while event looping is done in the main thread. In both
>> places XOpenDisplay(
wo display would access X
at the same time. Would this help?
On 1/19/20 6:28 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 19 Jan 2020 15:17:17 +0100 Roland Plüss said:
>
>> Hi Lucien,
>>
>> Depends what you call the same display. The window is created in the
>> r
I've added now an event loop to the render thread using that display
connection. This seems to work. Come to think of it this is actually not
so bad anyways. Moved some events over to that event loop. In the end I
need the main loop only for input handling so these events can go to the
render threa
ad no
superior application performance. So I'm used to juggle loaded guns with
safety triggers off :D
On 1/20/20 9:47 AM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 19 Jan 2020 19:05:58 +0100 Roland Plüss said:
>
>> In many cases I can do it purely on the render thread onl
18 matches
Mail list logo
