Qt integration

[m0bl0]

Hello everyone,

I've been working on a Qt integration for Equalizer. So, I implemented an eq::OSWindow for Qt and overloaded eq::Window::configInitOSWindow to create my QtWindow. I can get Equalizer to render into the Qt widget, but now I'm struggling with event handling:

I receive events in the main thread (which created the widget, because it's the only one allowed to in Qt), and need to get them to the Pipe thread. I think the "correct" approach would be to repost the events on the Pipe thread, and implement a QtMessagePump to retrieve and dispatch them. However, the creation of the window system-specific MessagePump is hardcoded (in eq::CommandQueue::setWindowSystem), and I don't see a way to get my hypothetical QtMessagePump in there without patching Equalizer, which I'd very much like to avoid.

So, am I missing something here? Is there a better approach to event handling? Or was something like this just never anticipated?

Thanks,
Marc

[Stefan Eilemann]

Hi Marc,

On 16. Jul 2009, at 14:28, m0bl0 wrote:

> I've been working on a Qt integration for Equalizer. [...]

Nice - this is in fact on Eq's feature list. Can you contribute this  
work?

> I'm struggling with event handling:
>
> I receive events in the main thread (which created the widget,  
> because it's
> the only one allowed to in Qt), and need to get them to the Pipe  
> thread.

Why? Do you have issues with processing them on the main thread?

> I think the "correct" approach would be to repost the events on the  
> Pipe
> thread, and implement a QtMessagePump to retrieve and dispatch them.
> However, the creation of the window system-specific MessagePump is  
> hardcoded
> (in eq::CommandQueue::setWindowSystem), and I don't see a way to get  
> my
> hypothetical QtMessagePump in there without patching Equalizer,  
> which I'd
> very much like to avoid.

Understood.

The correct way is to analyze the event handling needs of the typical  
Qt application, find the correct solution and change Equalizer  
accordingly.

To that end, can you write down what you want to do in your  
application? My feeling is that one would want to leave the event  
handling completely to Qt (in the main thread), and only catch the  
resize/close events to give update Equalizer entities.

> So, am I missing something here?

No, this hasn't been a use case yet.


HTH,

Stefan.

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[m0bl0]

Hi Stefan,

Stefan Eilemann wrote:

Can you contribute this work?

Yes, I definitely will, once it's in a somewhat more presentable state ;) (or earlier, if someone wants to help!)

Stefan Eilemann wrote:

Why? Do you have issues with processing them on the main thread?

I guess mouse and keyboard events could be handled in the main thread, but the window events (resize/show/hide etc) have to be forwarded to Equalizer.

Stefan Eilemann wrote:

The correct way is to analyze the event handling needs of the typical  
Qt application, find the correct solution and change Equalizer  
accordingly.

To that end, can you write down what you want to do in your  
application? My feeling is that one would want to leave the event  
handling completely to Qt (in the main thread), and only catch the  
resize/close events to give update Equalizer entities.

I don't think I understand what you mean by "what I want to do in my application".
As you say, I need to forward window events to Equalizer, more specifically, to the Pipe thread.

Cheers,
Marc

[Stefan Eilemann]

On 17. Jul 2009, at 14:12, m0bl0 wrote:

>> Why? Do you have issues with processing them on the main thread?
>
> I guess mouse and keyboard events could be handled in the main  
> thread, but
> the window events (resize/show/hide etc) have to be forwarded to  
> Equalizer.

You could just handle them by setting the PixelViewport on the  
eq::Window, similar to Window::processEvent. Equalizer doesn't need  
the native events.

Does that help you?


Cheers,

Stefan.


_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[m0bl0]

Stefan Eilemann (via Nabble) wrote:
> You could just handle them by setting the PixelViewport on the  
> eq::Window, similar to Window::processEvent. Equalizer doesn't need  
> the native events.

Am I allowed to do that from another thread?
I tried to do it that way, but I occasionally get a failed EQASSERT in
Channel::processEvent:
client/channel.cpp:707: EQASSERT( _context == &_nativeContext )
(at svn rev. 3204)

This happens if the Pipe thread is currently e.g. in
Channel::_cmdFrameDraw and has set _context to something else than
_nativeContext.

So I assume I'm not supposed to call Equalizer's event handling
functions (or those that call them, like Window::setPixelViewport) from
another thread, is that correct?

Cheers,
Marc

[Stefan Eilemann]

On 17. Jul 2009, at 16:07, m0bl0 wrote:

> Stefan Eilemann (via Nabble) wrote:
> > You could just handle them by setting the PixelViewport on the
> > eq::Window, similar to Window::processEvent. Equalizer doesn't need
> > the native events.
>
> Am I allowed to do that from another thread?
> I tried to do it that way, but I occasionally get a failed EQASSERT in
> Channel::processEvent:
> client/channel.cpp:707: EQASSERT( _context == &_nativeContext )

Oh, I didn't think of that one. As said, the processing so far wasn't  
designed to be called from the main thread, but this is not a 'hard'  
design decision. In fact AGL used to do event processing from the main  
thread until a couple of months ago.

I've implemented this particular piece of code better, which made it  
thread-safe (hopefully) and removed the assertion.

Change #3207 is for you.


Let me know when you find anything else.


Best,

Stefan.


_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[Stefan Hutter]

Marc,

>> Can you contribute this work?
>Yes, I definitely will, once it's in a somewhat more presentable state ;)
>(or earlier, if someone wants to help!)

we are working on a students project having the same goal. we would be glad to help with the qt integration into eqply. can you contribute the code right now so we can fix remaining issues together?

regards

daniel pfeifer
stefan hutter

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[m0bl0]

Stefan Eilemann wrote:

On 17. Jul 2009, at 16:07, m0bl0 wrote:

Oh, I didn't think of that one. As said, the processing so far wasn't  
designed to be called from the main thread, but this is not a 'hard'  
design decision. In fact AGL used to do event processing from the main  
thread until a couple of months ago.

I've implemented this particular piece of code better, which made it  
thread-safe (hopefully) and removed the assertion.

Change #3207 is for you.

Thanks, now it seems to work!
What I do now is translate the events I receive from Qt to eq::Events, and call Window::processEvent, like the other OSWindows do.

Stefan Eilemann wrote:

Let me know when you find anything else.

A few more things:

An eq::Event contains a RenderContext, but Window::getRenderContext may only be called by the pipe thread. So far, I just leave it empty, which doesn't seem to cause problems, but I assume it's there for a reason?

Also, occasionally I get an error during shutdown in Pipe::_releaseViews in pipe.cpp:379 in rev 3207 (the variable "view" is null), but I haven't gotten around to finding out what causes this...

Thanks again,
Marc

[m0bl0]

Stefan Hutter wrote:

can you contribute the code right now so we can fix remaining issues together?

I'll make a SourceForge project when I get around to it one of these days... if it's urgent, send me a private message containing your email address, and I'll email it to you (Nabble's "send private email" function doesn't allow attachments)

Cheers,
Marc

[Stefan Eilemann]

On Mon, Jul 20, 2009 at 6:15 PM, m0bl0<[hidden email]> wrote:
> What I do now is translate the events I receive from Qt to eq::Events, and
> call Window::processEvent, like the other OSWindows do.

Sounds reasonable.

> An eq::Event contains a RenderContext, but Window::getRenderContext may only
> be called by the pipe thread. So far, I just leave it empty, which doesn't
> seem to cause problems, but I assume it's there for a reason?

It's a utility to find the channel's rendering context for a pointer
event, e.g., to do picking.

Since the channel data changes constantly, the window stores all
channel render context from the last frame. Since this vector is
updated from the pipe thread, it is not thread-safe to access from
another thread. In the old AGL days it used to have a lock around,
which is not the proper solution.

Right now you don't need it, and I'll keep it in mind to find a better solution.


> Also, occasionally I get an error during shutdown in Pipe::_releaseViews in
> pipe.cpp:379 in rev 3207 (the variable "view" is null), but I haven't gotten
> around to finding out what causes this...

A stack trace would help...



Cheers,

Stefan.

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[m0bl0]

Stefan Eilemann wrote:

> Also, occasionally I get an error during shutdown in Pipe::_releaseViews in
> pipe.cpp:379 in rev 3207 (the variable "view" is null), but I haven't gotten
> around to finding out what causes this...

A stack trace would help...

Right, here you go:

> Equalizer.dll!eq::net::Object::getVersion()  Line 324 + 0x5 bytes C++
  Equalizer.dll!eq::Pipe::_releaseViews()  Line 379 + 0xa bytes C++
  Equalizer.dll!eq::Pipe::_cmdFrameFinish(eq::net::Command & command={...})  Line 855 C++
  Equalizer.dll!eq::net::CommandFunc<eq::net::Dispatcher>::operator()(eq::net::Command & command={...})  Line 51 C++
  Equalizer.dll!eq::net::Dispatcher::invokeCommand(eq::net::Command & command={...})  Line 126 C++
  Equalizer.dll!eq::net::Session::_invokeObjectCommand(eq::net::Command & command={...})  Line 591 + 0x1e bytes C++
  Equalizer.dll!eq::net::Session::invokeCommand(eq::net::Command & command={...})  Line 546 + 0xf bytes C++
  Equalizer.dll!eq::Pipe::_runThread()  Line 280 + 0x15 bytes C++
  Equalizer.dll!eq::Pipe::PipeThread::run()  Line 459 + 0x31 bytes C++
  Equalizer.dll!eq::base::Thread::_runChild()  Line 139 + 0x16 bytes C++
  Equalizer.dll!eq::base::Thread::runChild(void * arg=0x0000000002c473c0)  Line 113 C++
  pthreadVC2.dll!00000000100031f7()
  [Frames below may be incorrect and/or missing, no symbols loaded for pthreadVC2.dll]
  msvcr80.dll!00000000745c37d7()
  msvcr80.dll!00000000745c3894()
  kernel32.dll!0000000076b2be3d()
  ntdll.dll!0000000076d36a51()



On another note: Is there a way to reopen bugs in the SourceForge bug tracker, or should I just repost? 2803528 (assertion with zero area pvps) still happens for me...

Cheers,
Marc

[Stefan Eilemann]

On Mon, Jul 20, 2009 at 7:00 PM, m0bl0<[hidden email]> wrote:

> On another note: Is there a way to reopen bugs in the SourceForge bug
> tracker, or should I just repost? 2803528 (assertion with zero area pvps)
> still happens for me...

You need to login to submit bugs. If you're logged in and still can't
re-open bugs then you can't obviously reopen bugs on sourceforge. Just
open a new one in this case.


Cheers,

Stefan.

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[Stefan Eilemann]

On Mon, Jul 20, 2009 at 7:00 PM, m0bl0<[hidden email]> wrote:
>>> Also, occasionally I get an error during shutdown in Pipe::_releaseViews
>>> in
>>> pipe.cpp:379 in rev 3207 (the variable "view" is null), but I haven't
>>> gotten
>>> around to finding out what causes this...
>>
>> A stack trace would help...
>
> Right, here you go:

Ah, nice :-/

The channel event handler maps a view, which is stored in a per-pipe
map. This map is updated from the pipe thread...

Revision #3210 fixes this and adds a couple of assertions as a safeguard.


HTH,

Stefan.
--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[m0bl0]

Okay, I *finally* created that SourceForge project. You can now get the code via svn:

https://eqqt.svn.sourceforge.net/svnroot/eqqt/trunk

Cheers,
Marc