Right now the main thread is only responsible for anything input related and the render thread only looks at this one event that caused troubles. So far I did not encounter any problems I did not see in single-connection cases too.
I'll take the warning into account. But without render thread 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 <rol...@rptd.ch> said:
>
>> In many cases I can do it purely on the render thread only if this
>> helps. If though a toolkit is involved (FOX in this case) then I need to
>> "inject" the render window.
>>
>> I can prevent synchronization issues easily if this is required as I
>> have a specific synchronization window so no two display would access X
>> at the same time. Would this help?
> well you already hit a problem... you had events going to different places.
> you'll hit more as time goes on if you use 2 display connections and actively
> do different things in each. especially things like create a window in one of
> them then listen for events for it in another. you will find wonderful gotchas
> like only one of those display connections can get mouse button press/release
> events, both can get mouse motion but only until some button is held down...
> in
> this case "first come, the only one served". you will find things like
> handling
> of operation now goes out of order. i hope you set an x error handler rather
> than rely on the standard xlib one too... or you're in even deeper trouble
> etc.
>
> just fair warning. you walk down a dangerous path i wouldn't advise unless you
> are an old x hack who has been around the block a few times and knows the
> nasties that shall happen... :)
>
>> On 1/19/20 6:28 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Sun, 19 Jan 2020 15:17:17 +0100 Roland Plüss <rol...@rptd.ch> said:
>>>
>>>> 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(getenv("DISPLAY")) is called. Is this not the same
>>>> display? If not how can I "attach" them together? It's a requirement
>>>> that the render thread creates the window while the main thread has to
>>>> handle the event loop (to my knowledge only this works).
>>> you use 2 display handles? oooooh... you're asking for trouble. you're
>>> asking for ownesrship and lifecycle issues there as well as race conditions.
>>>
>>> xlib can handle threads on the same Display handle, you just need to
>>> XInitThreads() before you go using more than 1 thread with it. :)
>>>
>>>> On 1/19/20 2:43 PM, Lucien Gentis wrote:
>>>>> Hello Roland,
>>>>>
>>>>> While defining delAtom and calling XSetWMProtocls, you specifiy
>>>>> "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 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 );
>>>>>> XSetWMProtocols( display, pWindow, &delAtom, 1 );
>>>>>>
>>>>>> The window will not be destroyed when X is pressed so I think this
>>>>>> worked. The problem is though that I do not received ClientMessage and
>>>>>> thus I am unable to close the window. This is the event loop:
>>>>>>
>>>>>> XEvent event;
>>>>>> while( XPending( pDisplay ) ){
>>>>>> XNextEvent( pDisplay, &event );
>>>>>> log("Event %d", event.type);
>>>>>> switch( event.type ){
>>>>>> ...
>>>>>> case ClientMessage:
>>>>>> log("Quit Request Received");
>>>>>> break;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Window is created like this:
>>>>>>
>>>>>> #define BASIC_EVENT_MASK ( StructureNotifyMask | ExposureMask |
>>>>>> PropertyChangeMask \
>>>>>> | EnterWindowMask | LeaveWindowMask |
>>>>>> KeyPressMask \
>>>>>> | KeyReleaseMask | KeymapStateMask |
>>>>>> FocusChangeMask )
>>>>>>
>>>>>> #define NOT_PROPAGATE_MASK ( KeyPressMask | KeyReleaseMask |
>>>>>> ButtonPressMask \
>>>>>> | ButtonReleaseMask | PointerMotionMask |
>>>>>> ButtonMotionMask )
>>>>>>
>>>>>> XSetWindowAttributes swa;
>>>>>> swa.colormap = colMap;
>>>>>> swa.backing_store = NotUseful;
>>>>>> swa.border_pixel = 0;
>>>>>> swa.event_mask = BASIC_EVENT_MASK;
>>>>>> swa.do_not_propagate_mask = NOT_PROPAGATE_MASK;
>>>>>> swa.override_redirect = False;
>>>>>> swa.save_under = False;
>>>>>> swa.cursor = 0;
>>>>>> swa.bit_gravity = ForgetGravity;
>>>>>> swa.win_gravity = NorthWestGravity;
>>>>>>
>>>>>> Any idea what else I need to do to get this working?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> xorg@lists.x.org: X.Org support
>>>>>> Archives: http://lists.freedesktop.org/archives/xorg
>>>>>> Info: https://lists.x.org/mailman/listinfo/xorg
>>>>>> Your subscription address: %(user_address)s
>>>>> _______________________________________________
>>>>> xorg@lists.x.org: X.Org support
>>>>> Archives: http://lists.freedesktop.org/archives/xorg
>>>>> Info: https://lists.x.org/mailman/listinfo/xorg
>>>>> Your subscription address: %(user_address)s
>>>> --
>>>> Mit freundlichen Grüssen
>>>> Plüss Roland
>>>>
>>>> Leader und Head Programmer
>>>> - Game: Epsylon ( http://www.indiedb.com/games/epsylon )
>>>> - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
>>>> , http://dragengine.rptd.ch/wiki )
>>>> - Sowie verschiedene Blender Export-Skripts und Game-Tools
>> --
>> Mit freundlichen Grüssen
>> Plüss Roland
>>
>> Leader und Head Programmer
>> - Game: Epsylon ( http://www.indiedb.com/games/epsylon )
>> - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
>> , http://dragengine.rptd.ch/wiki )
>> - Sowie verschiedene Blender Export-Skripts und Game-Tools
>>
>
--
Yours sincerely
Plüss Roland
Leader and Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch/wiki )
- As well as various Blender export scripts und game tools
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
