<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 Geoff, Chris,</p>
<p style="margin:0px 0px 1.2em!important">IMHO, there are two approaches to VTK+QtQuick:</p>
<ul style="margin:1.2em 0px;padding-left:2em">
<li style="margin:0.5em 0px"><p style="margin:0px 0px 1.2em!important;margin:0.5em 0px!important">Rendering the VTK scene to a QQuickFrameBufferObject.</p>
<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em">
<li style="margin:0.5em 0px">Provides better integration with the QML render stack.</li>
<li style="margin:0.5em 0px">Since it is an indirect rendering approach, performance may suffer.</li>
<li style="margin:0.5em 0px">May require specializations for some VTK interactor styles and VTK widget interaction.</li>
</ul>
</li>
<li style="margin:0.5em 0px"><p style="margin:0px 0px 1.2em!important;margin:0.5em 0px!important">Rendering directly to the QML created OpenGL context using <code style="font-size:0.95em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(218,218,218);background-color:rgb(232,232,232);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">beforeRendering()</code> and <code style="font-size:0.95em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(218,218,218);background-color:rgb(232,232,232);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">afterRendering()</code> calls</p>
<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em">
<li style="margin:0.5em 0px">Better performance as VTK is directly rendering to the FrameBuffer</li>
<li style="margin:0.5em 0px">Interactor styles and widget interaction would work out of the box</li>
<li style="margin:0.5em 0px">Does not fit within the QML stack as the VTK scene would either be an underlay or an overlay</li>
</ul>
</li>
</ul>
<p style="margin:0px 0px 1.2em!important">Note that in both these approaches, VTK rendering would need to be constrained to the <code style="font-size:0.95em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(218,218,218);background-color:rgb(232,232,232);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">QSGRenderThread</code> and Qt events would have to be queued before being processed on the render thread.</p>
<p style="margin:0px 0px 1.2em!important">Considering that both these approaches have their own merits, demerits and constraints, maybe adding a compile time flag that lets you switch between direct and indirect rendering would help. As such, there is no “correct” solution.</p>
<p style="margin:0px 0px 1.2em!important">Regarding queueing the events, I’d just sub-class <a href="http://www.vtk.org/doc/nightly/html/classQVTKInteractorAdapter.html">QVTKInteractorAdapter</a> and override <code style="font-size:0.95em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(218,218,218);background-color:rgb(232,232,232);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">ProcessEvent</code> so that the event gets queued. One execution is in the render thread, the queued events should be processed by the interactor.</p>
<p style="margin:0px 0px 1.2em!important">One more thing as Geoff pointed out, since QML creates an OpenGL context, each VTK item in that context would be an independent <code style="font-size:0.95em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(218,218,218);background-color:rgb(232,232,232);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">vtkViewport</code>. Without this, having multiple QML and VTK items in the same window would not be possible.</p>
<p style="margin:0px 0px 1.2em!important">Hope this helps.</p>
<p style="margin:0px 0px 1.2em!important">Sankhesh</p>
<div title="MDH:SGkgR2VvZmYsIENocmlzLDxkaXY+PGJyPjwvZGl2PjxkaXY+SU1ITywgdGhlcmUgYXJlIHR3byBh
cHByb2FjaGVzIHRvIFZUSytRdFF1aWNrOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LSBSZW5k
ZXJpbmcgdGhlIFZUSyBzY2VuZSB0byBhIFFRdWlja0ZyYW1lQnVmZmVyT2JqZWN0LjwvZGl2Pjxk
aXY+Jm5ic3A7ICZuYnNwOy0gUHJvdmlkZXMgYmV0dGVyIGludGVncmF0aW9uIHdpdGggdGhlIFFN
TCByZW5kZXIgc3RhY2suPC9kaXY+PGRpdj4mbmJzcDsgJm5ic3A7LSBTaW5jZSBpdCBpcyBhbiBp
bmRpcmVjdCByZW5kZXJpbmcgYXBwcm9hY2gsIHBlcmZvcm1hbmNlIG1heSBzdWZmZXIuPC9kaXY+
PGRpdj4mbmJzcDsgJm5ic3A7LSBNYXkgcmVxdWlyZSBzcGVjaWFsaXphdGlvbnMgZm9yIHNvbWUg
VlRLIGludGVyYWN0b3Igc3R5bGVzIGFuZCBWVEsgd2lkZ2V0IGludGVyYWN0aW9uLjwvZGl2Pjxk
aXY+PGJyPjwvZGl2PjxkaXY+LSBSZW5kZXJpbmcgZGlyZWN0bHkgdG8gdGhlIFFNTCBjcmVhdGVk
IE9wZW5HTCBjb250ZXh0IHVzaW5nIGBiZWZvcmVSZW5kZXJpbmcoKWAgYW5kIGBhZnRlclJlbmRl
cmluZygpYCBjYWxsczwvZGl2PjxkaXY+Jm5ic3A7IC0gQmV0dGVyIHBlcmZvcm1hbmNlIGFzIFZU
SyBpcyBkaXJlY3RseSByZW5kZXJpbmcgdG8gdGhlIEZyYW1lQnVmZmVyPC9kaXY+PGRpdj4mbmJz
cDsgLSBJbnRlcmFjdG9yIHN0eWxlcyBhbmQgd2lkZ2V0IGludGVyYWN0aW9uIHdvdWxkIHdvcmsg
b3V0IG9mIHRoZSBib3g8L2Rpdj48ZGl2PiZuYnNwOyAtIERvZXMgbm90IGZpdCB3aXRoaW4gdGhl
IFFNTCBzdGFjayBhcyB0aGUgVlRLIHNjZW5lIHdvdWxkIGVpdGhlciBiZSBhbiB1bmRlcmxheSBv
ciBhbiBvdmVybGF5PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ob3RlIHRoYXQgaW4gYm90aCB0
aGVzZSBhcHByb2FjaGVzLCBWVEsgcmVuZGVyaW5nIHdvdWxkIG5lZWQgdG8gYmUgY29uc3RyYWlu
ZWQgdG8gdGhlIGBRU0dSZW5kZXJUaHJlYWRgIGFuZCBRdCBldmVudHMgd291bGQgaGF2ZSB0byBi
ZSBxdWV1ZWQgYmVmb3JlIGJlaW5nIHByb2Nlc3NlZCBvbiB0aGUgcmVuZGVyIHRocmVhZC48L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNvbnNpZGVyaW5nIHRoYXQgYm90aCB0aGVzZSBhcHByb2Fj
aGVzIGhhdmUgdGhlaXIgb3duIG1lcml0cywgZGVtZXJpdHMgYW5kIGNvbnN0cmFpbnRzLCBtYXli
ZSBhZGRpbmcgYSBjb21waWxlIHRpbWUgZmxhZyB0aGF0IGxldHMgeW91IHN3aXRjaCBiZXR3ZWVu
IGRpcmVjdCBhbmQgaW5kaXJlY3QgcmVuZGVyaW5nIHdvdWxkIGhlbHAuIEFzIHN1Y2gsIHRoZXJl
IGlzIG5vICJjb3JyZWN0IiBzb2x1dGlvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlJlZ2Fy
ZGluZyBxdWV1ZWluZyB0aGUgZXZlbnRzLCBJJ2QganVzdCBzdWItY2xhc3MgW1FWVEtJbnRlcmFj
dG9yQWRhcHRlcl0oPGEgaHJlZj0iaHR0cDovL3d3dy52dGsub3JnL2RvYy9uaWdodGx5L2h0bWwv
Y2xhc3NRVlRLSW50ZXJhY3RvckFkYXB0ZXIuaHRtbCI+aHR0cDovL3d3dy52dGsub3JnL2RvYy9u
aWdodGx5L2h0bWwvY2xhc3NRVlRLSW50ZXJhY3RvckFkYXB0ZXIuaHRtbDwvYT4pIGFuZCBvdmVy
cmlkZSBgUHJvY2Vzc0V2ZW50YCBzbyB0aGF0IHRoZSBldmVudCBnZXRzIHF1ZXVlZC4gT25lIGV4
ZWN1dGlvbiBpcyBpbiB0aGUgcmVuZGVyIHRocmVhZCwgdGhlIHF1ZXVlZCBldmVudHMgc2hvdWxk
IGJlIHByb2Nlc3NlZCBieSB0aGUgaW50ZXJhY3Rvci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2
Pk9uZSBtb3JlIHRoaW5nIGFzIEdlb2ZmIHBvaW50ZWQgb3V0LCBzaW5jZSBRTUwgY3JlYXRlcyBh
biBPcGVuR0wgY29udGV4dCwgZWFjaCBWVEsgaXRlbSBpbiB0aGF0IGNvbnRleHQgd291bGQgYmUg
YW4gaW5kZXBlbmRlbnQgYHZ0a1ZpZXdwb3J0YC4gV2l0aG91dCB0aGlzLCBoYXZpbmcgbXVsdGlw
bGUgUU1MIGFuZCBWVEsgaXRlbXMgaW4gdGhlIHNhbWUgd2luZG93IHdvdWxkIG5vdCBiZSBwb3Nz
aWJsZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkhvcGUgdGhpcyBoZWxwcy48L2Rpdj48ZGl2
Pjxicj48L2Rpdj48ZGl2PlNhbmtoZXNoPC9kaXY+" 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 10:14 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">Hi Geoff,<br>
<br>
as I understand it, the blog post you linked to doesn't mention<br>
multiple threads beyond the QML UI thread and the scenegraph render<br>
thread.<br>
<br>
So far, I am using that approach with QQuickFrameBufferObject as<br>
starting point and vtkExternalOpenGLRenderWindow for the VTK side,<br>
which causes VTK to use QML's OpenGL context and thus render into the<br>
FBO maintained by QQuickFrameBufferObject. That seems to work<br>
flawlessly, as long as ALL rendering is kept on the scenegraph thread,<br>
which is not always obvious to do at first, because VTK's API's don't<br>
separate between reading event values and rendering them (e.g.,<br>
SetSlice(2) will internally set the current slice and then do a<br>
Render()).<br>
<br>
But why maintain more threads?<br>
<br>
Anyway, please go ahead and explain your approach as detailed as<br>
possible, I am all ears.<br>
<br>
regards,<br>
Chris<br>
<br>
Zitat von Geoff Wright <<a href="mailto:gpwright@gmail.com" target="_blank">gpwright@gmail.com</a>>:<br>
<br>
> Hi guys,<br>
><br>
> I would argue that for qml integration the best approach is for each vtk<br>
> viewport to render into a texture on a dedicated thread, not the qml<br>
> rendering thread.  Qml then draws the resulting texture which is more in<br>
> line with the Qt design intention ( see<br>
> <a href="http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/" rel="noreferrer" target="_blank">http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/</a><br>
>  )<br>
><br>
> I have been using this approach for a couple of years in a high performance<br>
> real time application.  The code is unfortunately proprietary but very<br>
> happy to explain more about the approach.  It would be great to add support<br>
> for this to VTK.<br>
><br>
> For the interactor part I do what Sankesh said, defer the events and apply<br>
> them on the render thread of the particular vtk item.<br>
><br>
> Regards,<br>
><br>
> G<br>
><br>
><br>
><br>
> On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri <<a href="mailto:sankhesh.jhaveri@kitware.com" target="_blank">sankhesh.jhaveri@kitware.com</a>><br>
> wrote:<br>
><br>
>> Hi Christian,<br>
>><br>
>> Doing all VTK rendering on the QML render thread is the right thing to do.<br>
>> As far as interaction is concerned, make sure that Qt events are queued on<br>
>> the main thread and processed when execution reaches the render thread.<br>
>><br>
>> I have done some work on VTK and QtQuick integration that I’m planning to<br>
>> add to a VTK remote module. That way, it will be available as part of VTK.<br>
>><br>
>> Thanks,<br>
>> Sankhesh<br>
>> ​<br>
>><br>
>> On Tue, May 16, 2017 at 4:57 AM <<a href="mailto:c.sell@byterefinery.de" target="_blank">c.sell@byterefinery.de</a>> wrote:<br>
>><br>
>>> 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:<br>
>>> <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<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>
>> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware<br>
>> <<a href="http://www.kitware.com/" rel="noreferrer" target="_blank">http://www.kitware.com/</a>> | <a href="tel:(518)%20881-4417" value="+15188814417" target="_blank">(518) 881-4417</a><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>
<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>