Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3361 tweak ctk vtk connection with benchmark #475

Closed

Conversation

jcfr
Copy link
Member

@jcfr jcfr commented May 27, 2014

No description provided.

jcfr added 14 commits May 21, 2014 13:38
This commit allows CTK to be compiler against VTK6 with testing enabled.
That said, there are some tests failing to pass. Issues commontk#467, commontk#468, commontk#469
and commontk#471 track the failure most likely related to VTK6.
…nnection

* fix-test-compile-against-vtk6:
  Fix compilation of tests against VTK6
In case the debug statement is used in the destructor, this commit
will prevent the application from crashing.
By using ctkCallback instead of QTimer, we can associate
a function that increment a counter each it is invoked. This
allows to check that the Qt slot or VTK callback have been invoked.

This commit also compute the stats associated with the connection5.
…ndently

This is particularly useful when instrumenting the code and running
callgrind on each test case independently.
This can be useful for both providing a custom implementation and for testing.
* Use vtkWeakPointer to track the VTK object. The observation of the
DeleteEvent is now required only to disconnect the Qt slots. Using a weak
pointer also ensure that the pointer to VTK object will be set to zero
with/without observing deletion.

* Simplify ctkVTKConnection: There is not need to explicitly disconnect
slots when object is deleted. Indeed, according to Qt documentation, "all
signals to and from the object are automatically disconnected" there is no
need to explicitly disconnect them."
[1] http://qt-project.org/doc/qt-4.8/qobject.html#dtor.QObject

By also removing the call to 'disconnectSlots' in the 'disconnect()' function,
it resolves Slicer issue #3361 [2] where it was reported "No such slot" error.
Since the disconnect happened in the connection destructor and the connection
were destroyed in the base class but the slot belonged to the derived class,
this explained the error message.

[2] http://www.na-mic.org/Bug/view.php?id=3361

* Simplify ctkVTKConnection: There is no need to explicit remove VTK
observers where connection is deleted. Indeed, observers of a VTK object
are automatically removed when an object is deleted.
Now the VTK pointer is set to zero independently of the DeleteEvent
observation, the observation is only needed to explicitly
disconnect the Qt slots. Since keeping the connected slots around doesn't
impact performance, this commit disabled the "deletion" observation.

If needed, a future additional improvement would be the pruning of
connection there are associated with deleted VTK object. This could be
done in the same loop taking care of shadow connection.

Results of ctkVTKObjectTest1:

[ObserveDeletion = true]
148: Create  10000  connections...
148:   elapsed time:  3.06955 seconds
148: Remove  10000  connections...
148:   elapsed time:  3.44588 seconds

[ObserveDeletion = false]
148: Create  10000  connections...
148:   elapsed time:  0.775543 seconds
148: Remove  10000  connections...
148:   elapsed time:  0.760212 seconds
@jcfr
Copy link
Member Author

jcfr commented May 27, 2014

@lassoan @finetjul I did some tweak of the ctkVTKConnection. Let me know what you think. I will rebase against current master later. Thks

As discussed in [1], the test should check that the code works
as expected and not set a bar that we cannot yet attain.

[1] commontk#378 (comment)
@jcfr jcfr closed this May 27, 2014
@jcfr jcfr deleted the 3361-tweak-ctkVTKConnection-with-benchmark branch May 27, 2014 17:26
@jcfr
Copy link
Member Author

jcfr commented May 27, 2014

A branch rebased against current master have been pushed here: #476

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant