<div dir="ltr"><div class="markdown-here-wrapper" style="font-family:'Lucida Sans',Verdana,sans-serif;color:rgb(11,83,148)"><p style="margin:0px 0px 1.2em!important">Hi Christian,</p>
<p style="margin:0px 0px 1.2em!important">Doing all VTK rendering on the QML render thread is the right thing to do. As far as interaction is concerned, make sure that Qt events are queued on the main thread and processed when execution reaches the render thread.</p>
<p style="margin:0px 0px 1.2em!important">I have done some work on VTK and QtQuick integration that I’m planning to add to a VTK remote module. That way, it will be available as part of VTK.</p>
<p style="margin:0px 0px 1.2em!important">Thanks,<br>Sankhesh</p>
<div title="MDH:SGkgQ2hyaXN0aWFuLDxkaXY+PGJyPjwvZGl2PjxkaXY+RG9pbmcgYWxsIFZUSyByZW5kZXJpbmcg
b24gdGhlIFFNTCByZW5kZXIgdGhyZWFkIGlzIHRoZSByaWdodCB0aGluZyB0byBkby4gQXMgZmFy
IGFzIGludGVyYWN0aW9uIGlzIGNvbmNlcm5lZCwgbWFrZSBzdXJlIHRoYXQgUXQgZXZlbnRzIGFy
ZSBxdWV1ZWQgb24gdGhlIG1haW4gdGhyZWFkIGFuZCBwcm9jZXNzZWQgd2hlbiBleGVjdXRpb24g
cmVhY2hlcyB0aGUgcmVuZGVyIHRocmVhZC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgaGF2
ZSBkb25lIHNvbWUgd29yayBvbiBWVEsgYW5kIFF0UXVpY2sgaW50ZWdyYXRpb24gdGhhdCBJJ20g
cGxhbm5pbmcgdG8gYWRkIHRvIGEgVlRLIHJlbW90ZSBtb2R1bGUuIFRoYXQgd2F5LCBpdCB3aWxs
IGJlIGF2YWlsYWJsZSBhcyBwYXJ0IG9mIFZUSy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRo
YW5rcyw8L2Rpdj48ZGl2PlNhbmtoZXNoPC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 16, 2017 at 4:57 AM <<a href="mailto:c.sell@byterefinery.de">c.sell@byterefinery.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">just for the record (nobody care about this subject?):<br>
<br>
I found that contrary to what I said I had NOT adhered to the<br>
principle established with protoype 1 while implementing protoype 2.<br>
Rather, I had directly called into the VTK interactor from the QML UI<br>
thread. And because the VTK interactors immediately go into rendering,<br>
all hell broke loose.<br>
<br>
After cleaning up example 2 according to the rule laid out earlier<br>
("store event data in RenderDelegate, call update() on the QML item,<br>
pass the event to VTK inside RenderDelgate.Render()", all works well.<br>
<br>
What I would like to do is validate the solution against findings made<br>
elsewhere, and then establish the "canonical" way of integrating VTK<br>
with QML. As I said, there are some architectural quirks with the<br>
solution which I would also like to address.<br>
<br>
regards,<br>
Christian<br>
<br>
<br>
Zitat von <a href="mailto:c.sell@byterefinery.de" target="_blank">c.sell@byterefinery.de</a>:<br>
<br>
> Hello all,<br>
><br>
> I am looking into the possibility of replacing the 3D rendering<br>
> engine in my Qt5 / QML based mobile tablet-oriented application with<br>
> VTK. What I need is a first class QtQuick integration (not a hack or<br>
> workaround) that is 100% stable in every context (not an unusual<br>
> requirement, I admit). To my amazement, nothing of that kind seems<br>
> to exist (correct me if I'm wrong).<br>
><br>
> I went on to investigate what had been done so far and to implement<br>
> my first prototypes, using the QQuickFrameBufferObject approach.<br>
> From the very start this felt like an uphill battle, because VTK<br>
> seems to come from a Windowing background and is quite tightly<br>
> integrated with concepts that are not valid in a QML context.<br>
><br>
> I'll describe my findings together with the 2 prototypical QML items<br>
> I implemented:<br>
><br>
> 1st was an adaptation of the DICOM example which now runs as a QML<br>
> item. All user interaction is handled by QML and forwarded to VTK<br>
> (which is one thing that doesn't come naturally with VTK), and after<br>
> some non-elegant tweaking I was able to have the UI move from slice<br>
> to slice and re-render upon mouse wheel events as expected. The<br>
> problem here was, that QML insists on keeping mouse event handling<br>
> and OpenGL rendering on separate threads, with one "rendering<br>
> thread" dedicated to OpenGL. However, the pre-existing VTK<br>
> Interactors directly call Render() after reconfiguring the UI from<br>
> the mouse event data, which is an absolute QML No-Go. I had to<br>
> introduce a RenderDelegate that works somewhat like this:<br>
><br>
> QML mouse event:<br>
>     tell RenderDelegate about the event<br>
>     call update() on the QML item, which triggers rer-endering on<br>
> the dedicated thread<br>
> on the QML rendering thread:<br>
>     call Render() on the RenderWindow<br>
>     inside the RenderDelegate, look at whether a mouse event is<br>
> pending, and call the corresponding VTK mouse handler<br>
>     call the renderer's default Render() function while setting the<br>
> delegate's "Used" flag to false<br>
><br>
> 2nd was a QML item that displays a model loaded from a 3ds file. My<br>
> goal here was to move the model around using mouse drag events. I<br>
> took the lessons learned from the first example, threw in a<br>
> vtkInteractorStyleTrackballCamera and hoped for the best. First<br>
> thing I found was that I needed a specialized<br>
> RenderWindowInteractor, which I provided. When I realized that the<br>
> most important requirement for that class was to provide access to<br>
> timer functionality, I already got wary, as throwing around events<br>
> and doing stuff offline while on the QML rendering thread is never a<br>
> good idea. My fears came true when I finished wiring everything<br>
> together: I was able to move the model using the mouse, but after a<br>
> few moments things got whacky with error output written to the<br>
> console and finally a segemtation fault from deep inside VTK.<br>
><br>
> I still need to investigate the second example, but would like to<br>
> synchronize with the community at this point in order to avoid<br>
> errors/misconceptions on my side, to seek help if possible and to<br>
> offer my contribution to the VTK code base once this becomes<br>
> functional. My first impression is that there are some issues that<br>
> lie on an architectural level and cannot be (elegantly) dealt with<br>
> on the QML side alone. Any comments?<br>
><br>
> thanks,<br>
> Christian Sell<br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div class="inbox-markdown-here-wrapper" style="font-family:'proza libre',sans-serif;color:rgb(0,56,107)"><h5 id="inbox-sankhesh-jhaveri" style="margin:1.3em 0px 1em;padding:0px;font-size:1.1em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);font-weight:bold;color:rgb(11,65,148)">Sankhesh Jhaveri</h5>
<h6 id="inbox--sr-research-development-engineer-kitware-http-www-kitware-com-518-881-4417" style="margin:1.3em 0px 1em;padding:0px;font-size:1em;color:rgb(11,83,148);font-family:'open sans',sans-serif;font-weight:normal"><em>Sr. Research & Development Engineer</em> | <a href="http://www.kitware.com/">Kitware</a> | (518) 881-4417</h6>
<div title="MDH:PGIgc3R5bGU9ImZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDEx
LCA4MywgMTQ4KTsiPjxmb250IHNpemU9IjIiPiMjIyMjU2Fua2hlc2ggSmhhdmVyaTwvZm9udD48
L2I+PGRpdj48Zm9udCBjb2xvcj0iIzBiNTM5NCIgZmFjZT0idmVyZGFuYSwgc2Fucy1zZXJpZiIg
c2l6ZT0iMiI+PGI+PGJyPjwvYj48L2ZvbnQ+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
IGFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDExLCA4MywgMTQ4KTsiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogdmVyZGFuYSwgc2Fucy1zZXJpZjsiPjxpPiMjIyMjIypTci4gUmVzZWFy
Y2ggJmFtcDsgRGV2ZWxvcG1lbnQgRW5naW5lZXIqPC9pPiZuYnNwO3wmbmJzcDs8L3NwYW4+PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogdmVyZGFuYSwgc2Fucy1zZXJpZjsgY29sb3I6
IHJnYigxMSwgODMsIDE0OCk7Ij48YSBocmVmPSJodHRwOi8vd3d3LmtpdHdhcmUuY29tLyIgdGFy
Z2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcmdiKDE3LCA4NSwgMjA0KTsiPktpdHdhcmU8L2E+
Jm5ic3A7fCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IHZlcmRhbmEsIHNh
bnMtc2VyaWY7IGNvbG9yOiByZ2IoMTEsIDgzLCAxNDgpOyI+KDUxOCkgODgxLTQ0MTc8L3NwYW4+
PGJyPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogdmVyZGFu
YSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigxMSwgODMsIDE0OCk7Ij48L3NwYW4+PC9kaXY+PC9k
aXY+PC9kaXY+PC9kaXY+" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px">​</div></div></div></div>