vistavrtoolkit-general — General discussion and user support for the ViSTA libraries.

Re: [vistavrtoolkit-general] Problems with DFN-Node: Could not fetch movements of mouse scrollwheel on linux

[Ingo A. <iar...@ya...>]

OK, now its clear why you see the particular values and can not access 
the wheel state.

* you use freeglut, and I assume that the cmake script detected that 
correctly
* when using freeglut, the glutWheelFunc() is registered properly
* when using glut on X, all mapped buttons (this includes the wheel) are 
handled by glutMouseFunc(). Wheels are mapped as button 3 and 4 (by 
default), so they overwrite the values in the intermediate 
representation of the glut driver (this is a bug in the mouse driver 
code (for linux) of vista on trunk)
* after that, the mouse wheel func is called and this in turn overwrites 
wheel state values

With my patch, both the mouse function and the mouse-wheel func 
increment the wheel state by 1, giving you only even values.

This patch is thus not correct for freeglut on linux (but would work for 
non-freeglut on linux (that was my assumption)); the windows freeglut 
event handling does not map the wheel buttons for the normal mouse 
function, see my older mails. That is why it works out of the box.

Ingo.



Am 18.10.2012 09:05, schrieb Dan...@dl...:
> Dear Ingo,
>
> Am 10.10.2012 09:15, schrieb Dan...@dl...
> <mailto:Dan...@dl...>:
>
>  > We have compiled versions of ViSTA on our fileserver.
>
>  > I used this version and do not want to compile ViSTA on my own.
>
> Interesting. Can you tell, out of curiousity, what version of ViSTA do
> you have precompiled?
>
> Every version from ViSTA 10 to 13. They can be loaded as modules on the
> command line.
>
>> Therefore I don't know whether glut or freeglut is used in this version.
>
> Right, AFAIK there is no output in the vista binary. You can, however,
> use "ldd <binary>" to see what version is linked. AND, regardless of how
> the Vista libraries are compiled, the -> glut <- version would be
> interesting to know to see what one can do to drag the wheel stuff in.
>
> We use freeglut. The libraries name is libglut.so.3.8.0.
>
>  > The people who compiled ViStTA are on a conference until tomorrow.
>
>  > When they are back again, I will try to follow your advice.
>
>  > I will tell you about the results.
>
> Cool. So far any news?
>
> Yesterday I applied the patch you send me. It worked. The only minor
> issue still not solved is that the WHEEL_STATE on Linux always changes
> by two for each unit I turn the mouse wheel. So WHEEL_STATE only returns
> even values. On windows instead it changes by one for each unit I turn
> the scroll wheel. We solved this issue in our source code.
>
>> I am sure that I receive "(0,0)" only and not "(-1,0)" on WHEEL_STATE and WHEEL_DIR.
>
>  > If I add a Debug-Node to the interaction.xml this is displayed to.
>
> You get these valus when the wheel is turned? Or when you hit another
> button?
>
> In both cases. Even if I just move the mouse in the ViSTA window.
>
> I don't know whether I have written this before: On Windows 7 Vista 11
> supported the scroll wheel out off he box.

Re: [vistavrtoolkit-general] Problems with DFN-Node: Could not fetch movements of mouse scrollwheel on linux

[<iar...@ya...>]

Daniel!

Answers below.


Am 10.10.2012 09:15, schrieb Dan...@dl...:
> We have compiled versions of ViSTA on our fileserver. 
> I used this version and do not want to compile ViSTA on my own. 

Interesting. Can you tell, out of curiousity, what version of ViSTA do you have precompiled?

> Therefore I don't know whether glut or freeglut is used in this version. 

Right, AFAIK there is no output in the vista binary. You can, however, use "ldd <binary>" to see what version is linked. AND, regardless of how the Vista libraries are compiled, the -> glut <- version would be interesting to know to see what one can do to drag the wheel stuff in.

> The people who compiled ViStTA are on a conference until tomorrow. 
> When they are back again, I will try to follow your advice. 
> I will tell you about the results.

Cool. So far any news?

> I am sure that I receive "(0,0)" only and not "(-1,0)" on WHEEL_STATE and WHEEL_DIR. 
> If I add a Debug-Node to the interaction.xml this is displayed to.

You get these valus when the wheel is turned? Or when you hit another button? 

Ingo.

Re: [vistavrtoolkit-general] Problems with DFN-Node: Could not fetch movements of mouse scrollwheel on linux

[Ingo A. <iar...@ya...>]

I attach a patch to read mouse wheel with non-freeglut under linux. Note
that in theory, one can read any mapped button on X using glut,
including special mouse buttons (I know... the trend is to use just one
button ;)... but one could...)

However, my proposed solution will not work out of the box with windows
glut, and will fail if you, for whatever reasons, have remapped the
wheel under X to different button codes.

There is a patch for win32 glut available here:

http://www.realmtech.net/opengl/glut.php

I noticed that my freeglut (2.6.0-1ubuntu3) does not report mousewheel
callbacks on linux, so the patch might be considered as standard and
have the explicit freeglut dependency removed from the glut mouse driver.

Ingo.

p.s.:
@Daniel: it would be really nice to know which glut version you are using.

@Dominik: as X also maps other buttons, the current code could lead to
corruption, as we do not check the button index (l.105, #29742) when we
write the button value; IMO there should at least be a check/switch-case
whatever.


On 10/04/2012 10:11 PM, Ingo Assenmacher wrote:
> Hi!
> 
> There are some shortcomings on the current implementation as it is in
> Vista with regards to the wheel handling.
> 
> a) if you are using freeglut (which is most often default on Linux), you
> are fine off, but make sure that you compile the library using the
> USE_NATIVE_GLUT=0 preprocessor flag. Check your cmake cache file to see
> the value, os normally the cmake scripts make sure to detect whether you
> have freeglut or the 'only' the normal glut.
> 
> b) depending on your version of glut (here is where the 'luck' part
> starts), it reports mouse wheels as mouse button events. Check if you
> can find GLUT_WHEEL_<UP|DOWN> flags in your glut(.h). If that is the
> case, the Vista implementation is plainly not working good, as it does
> dispatch only the first three buttons and waits for magics to happen to
> the scroll wheel state. (In a nutshell: current glut implementations
> show the wheel as additional button).
> 
> Here is why you see 0 as a value:
> 
> in case the mouse button callback gets called (which happens if you use
> glut and not freeglut and you use the wheel), the mouse driver records
> the current state of the mouse. The right file to look at for your case
> would be
> VistaDeviceDrivers/VistaGlutMouseDriver/VistaGlutMouseDriver.cpp, l.
> 92f). This includes the current state of the variables for the wheel and
> the wheel state. As they are only changed in the case of freeglut
> installed, the state variables do not get updated. Are you sure you see
> "(0,0)" only? And not "(-1,0)"?
> 
> 
> The code, as it is right now can crash, so its good you pointed that
> out. It needs to be fixed. It would be very good to know what version of
> glut you are using and where we can peek at the source.
> 

Re: [vistavrtoolkit-general] Problems with DFN-Node: Could not fetch movements of mouse scrollwheel on linux

[Ingo A. <iar...@ya...>]

Hi!

There are some shortcomings on the current implementation as it is in
Vista with regards to the wheel handling.

a) if you are using freeglut (which is most often default on Linux), you
are fine off, but make sure that you compile the library using the
USE_NATIVE_GLUT=0 preprocessor flag. Check your cmake cache file to see
the value, os normally the cmake scripts make sure to detect whether you
have freeglut or the 'only' the normal glut.

b) depending on your version of glut (here is where the 'luck' part
starts), it reports mouse wheels as mouse button events. Check if you
can find GLUT_WHEEL_<UP|DOWN> flags in your glut(.h). If that is the
case, the Vista implementation is plainly not working good, as it does
dispatch only the first three buttons and waits for magics to happen to
the scroll wheel state. (In a nutshell: current glut implementations
show the wheel as additional button).

Here is why you see 0 as a value:

in case the mouse button callback gets called (which happens if you use
glut and not freeglut and you use the wheel), the mouse driver records
the current state of the mouse. The right file to look at for your case
would be
VistaDeviceDrivers/VistaGlutMouseDriver/VistaGlutMouseDriver.cpp, l.
92f). This includes the current state of the variables for the wheel and
the wheel state. As they are only changed in the case of freeglut
installed, the state variables do not get updated. Are you sure you see
"(0,0)" only? And not "(-1,0)"?


The code, as it is right now can crash, so its good you pointed that
out. It needs to be fixed. It would be very good to know what version of
glut you are using and where we can peek at the source.

Thanks, hope it helps,

Ingo.



On 10/04/2012 02:36 PM, Dominik Rausch wrote:
> What version of glut are you using? Standard glut does not support mouse
> wheels, but freeglut does, so you’ll have to built Vista with freeglut.

Re: [vistavrtoolkit-general] Problems with DFN-Node: Could not fetch movements of mouse scrollwheel on linux

[Dominik R. <ra...@vr...>]

Hi

 

What version of glut are you using? Standard glut does not support mouse
wheels, but freeglut does, so you’ll have to built Vista with freeglut.

 

Regards

  Dominik

 

--

 

Dipl.-Inform. Dominik Rausch
 
Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)
 
  Rechen- und Kommunikationszentrum
  Seffenter Weg 23, 52074 Aachen
  Tel. +49 241 80 29732
   <mailto:ra...@vr...> ra...@vr...
   <http://www.vr.rwth-aachen.de> www.vr.rwth-aachen.de

 

From: Dan...@dl... [mailto:Dan...@dl...] 
Sent: Thursday, October 04, 2012 1:32 PM
To: vis...@li...
Cc: Rob...@dl...; Rol...@dl...
Subject: [vistavrtoolkit-general] Problems with DFN-Node: Could not fetch
movements of mouse scrollwheel on linux

 

Hi all,

I am new to VISTA and try to pipe the scrollwheel movements of a normal
mouse via the DataFlowNet on Linux inside my programm

I am using VISTA 11 on SUSE Linux 11.

 I use the following interaction.xml file:

<module>
    <nodespace>
    </nodespace>

    <graph>
        <!-- data source... a mouse -->
        <node name="mouse" type="DriverSensor">
            <param name="sensor" value="0" />
            <param name="driver" value="MOUSE" />
        </node>

        <node name="flystick_action" type="Action">
            <param name="object" value="FlystickActionObject" />
        </node>

        <node name="project_mouse" type="HistoryProject">
            <param name="project">POSITION, LEFT_BUTTON, RIGHT_BUTTON,
MIDDLE_BUTTON, X_POS, Y_POS, WHEEL_STATE, WHEEL_DIR</param>
        </node>

        <node name="conv_wheel_state" type="TypeConvert[int,double]" />
        <node name="conv_wheel_dir" type="TypeConvert[int,double]" />

    </graph>
    <edges>
        <edge fromnode="mouse" tonode="project_mouse" fromport="history"
toport="history" />
 
        <edge fromnode="project_mouse" tonode="conv_wheel_state"
fromport="WHEEL_STATE" toport="in" />
        <edge fromnode="project_mouse" tonode="conv_wheel_dir"
fromport="WHEEL_DIR" toport="in" />

        <edge fromnode="conv_wheel_state" tonode="flystick_action"
fromport="out" toport="button_state_9" />
        <edge fromnode="conv_wheel_dir" tonode="flystick_action"
fromport="out" toport="button_state_10" />-->

      </edges>
</module>


Some parts of the interaction.ini. I hope I choose the interesting parts:

[3DMOUSE]
ROLE = 3DMOUSE
GRAPH = xml/mouse_ray.xml
#RELOADTRIGGER = T

[MOUSE]
TYPE = MOUSE
HISTORY = 10
SENSORS = MOUSE_MAIN
DEFAULTWINDOW = TRUE

[SPACENAVIGATOR]
TYPE = SPACENAVIGATOR
HISTORY = 10

[MOUSE_MAIN]
RAWID = 0



When the mousewheel is turned I receive zeros on button_state_9 and
button_state_10. 

In the source code of  VistaMouseDriver.cpp it looks as port "DSCALAR_3" of
"project_mouse" would contain the scrollwheel data. Therefore I also tried
to send DSCALAR_3 in my program. But it contains the same data as
"WHEEL_DIR" and "WHEEL_STATE".  

The state of the Left-, Right- and Middle-Button could be piped in my
programm without problems. 

The same problem occurs on Linux with Vista 13. On Windows with Vista 13
everything is fine. 

Have you any suggestions for me? Is there a workaround to get the
information about the scrollwheel movement on Linux?

Thank you for your help!

Best regards,
Daniel Homann

[vistavrtoolkit-general] Problems with DFN-Node: Could not fetch movements of mouse scrollwheel on linux

[<Dan...@dl...>]

Hi all,

I am new to VISTA and try to pipe the scrollwheel movements of a normal mouse via the DataFlowNet on Linux inside my programm

I am using VISTA 11 on SUSE Linux 11.

 I use the following interaction.xml file:

<module>
    <nodespace>
    </nodespace>

    <graph>
        <!-- data source... a mouse -->
        <node name="mouse" type="DriverSensor">
            <param name="sensor" value="0" />
            <param name="driver" value="MOUSE" />
        </node>

        <node name="flystick_action" type="Action">
            <param name="object" value="FlystickActionObject" />
        </node>

        <node name="project_mouse" type="HistoryProject">
            <param name="project">POSITION, LEFT_BUTTON, RIGHT_BUTTON, MIDDLE_BUTTON, X_POS, Y_POS, WHEEL_STATE, WHEEL_DIR</param>
        </node>

        <node name="conv_wheel_state" type="TypeConvert[int,double]" />
        <node name="conv_wheel_dir" type="TypeConvert[int,double]" />

    </graph>
    <edges>
        <edge fromnode="mouse" tonode="project_mouse" fromport="history" toport="history" />

        <edge fromnode="project_mouse" tonode="conv_wheel_state" fromport="WHEEL_STATE" toport="in" />
        <edge fromnode="project_mouse" tonode="conv_wheel_dir" fromport="WHEEL_DIR" toport="in" />

        <edge fromnode="conv_wheel_state" tonode="flystick_action" fromport="out" toport="button_state_9" />
        <edge fromnode="conv_wheel_dir" tonode="flystick_action" fromport="out" toport="button_state_10" />-->

      </edges>
</module>

Some parts of the interaction.ini. I hope I choose the interesting parts:

[3DMOUSE]
ROLE = 3DMOUSE
GRAPH = xml/mouse_ray.xml
#RELOADTRIGGER = T

[MOUSE]
TYPE = MOUSE
HISTORY = 10
SENSORS = MOUSE_MAIN
DEFAULTWINDOW = TRUE

[SPACENAVIGATOR]
TYPE = SPACENAVIGATOR
HISTORY = 10

[MOUSE_MAIN]
RAWID = 0


When the mousewheel is turned I receive zeros on button_state_9 and button_state_10.

In the source code of  VistaMouseDriver.cpp it looks as port "DSCALAR_3" of "project_mouse" would contain the scrollwheel data. Therefore I also tried to send DSCALAR_3 in my program. But it contains the same data as "WHEEL_DIR" and "WHEEL_STATE".

The state of the Left-, Right- and Middle-Button could be piped in my programm without problems.

The same problem occurs on Linux with Vista 13. On Windows with Vista 13 everything is fine.

Have you any suggestions for me? Is there a workaround to get the information about the scrollwheel movement on Linux?

Thank you for your help!

Best regards,
Daniel Homann

[vistavrtoolkit-general] ViSTA Release 1.14 "Pluto"

[Dominik R. <ra...@vr...>]

ViSTArians,

Today, the new VistaCoreLibs version 1.14 -- codename "PLUTO" -- has 
been released.
It is dedicated to formerly-a-planet-not-a-dwarf-planet Pluto. Being 
classified as a planet after its discovery on February 18, 1930, it was 
known as the ninth planet in our solar system until it was downgraded to 
a dwarf planet six years ago, on August 24, 2006. It is available now 
from the internal svn and as release package from sourceforge.

There are several additions from version 1.13. Most notably, a new 
ClusterMode has been added (mostly to support the new CAVE at RWTH 
Aachen University), providing added option/abstractions in cluster mode, 
like different synchroonization modes, and now also provides 
DataSyncEntities that can be used by an application to synchronize data 
among cluster nodes. For more information on the ClusterMode, check 
VistaKernel/Cluster/VistaNewCluster[MAster|Slave].h and the standard 
display_newcave.ini as an example. For the DataSyncEntities, take a look 
at VistaInterProcComm/Cluster.

In addition, several new DfnNodes have been added, namely 
QuaternionSlerp, Transform, Negate, LessEqual, Modulo, RangeCheck, 
Multiplex, Demultiplex, CropViewport, ProximityWarning, KeyCallback , 
Absolute, FadeoutNode, SimpleTextNode, ToggleNode, GeometryNode, 
PointingRay, OutstreamNode, and VariableNode.
Further important additions are the configurability of the framerate 
display and the output streams from the ini files (see the detailed log 
and code documentation for details).

The current release is mostly API-compatible with 1.13, the only 
significant change should be the replacement of 
VsitaRandomNumberGenerator::GetSingleton() with 
VistaRandomNumberGenerator::GetStandardRNG(), because now the RNG 
supports multiple (optionally thread local) instances. As usual, use the 
conversion script VistaTo1.14.py to automatically apply this change.

A full list of the changes can be found at 
https://wiki.sistec.dlr.de/VistaCoreLibsVersionLog or in the attached 
file vista-1.14-changes.

Regards
   Dominik

-- 

Dipl.-Inform. Dominik Rausch
  
Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)
  
   Rechen- und Kommunikationszentrum
   Seffenter Weg 23, 52074 Aachen
   Tel. +49 241 80 29732
   ra...@vr...
   www.vr.rwth-aachen.de

[vistavrtoolkit-general] Vista Release 1.13 "DARWIN"

[Dominik R. <ra...@vr...>]

 - **VistaKernel/Cluster/VistaClusterMaster: now supports multiple broadcast ports for swap syncing. This allowing for multiple slaves on one host. Use SYNCPORTS to provide comma-separated list of ports (SYNCPORT still works for single BC port, so no change required).**

 - VistaKernel/VistaSceneGraph:
  - **APICHG: SaveSubTree now accepts all IVistaNodes instead of just VistaGroupNodes**

 - **VistaMath/VistaBoundingBox:
  - APIADD: calls using VistaVectorMath types**
  - CHG: internal representation by VistaVector3D
  - STYLE: styleguide conformity

 - VistaKernel/GraphicsManager/VistaGeometry:
  - VistaMaterial:
   - **APIADD: Color-Getter/Setter now allow VistaColor in addition to float[3]**
   - **APICHG: GetName(), GetShininess(), GetOpacity() return float now (instead of using ref-to-float)**
  - VistaGeometry:
   - **APIADD: GetBoundingBox() with VistaBoundingBox return value**
  - STYLE: some more styleguides conformity
  
 - **Added VistaBase/VistaColor as a replacement of VistaColorRGB (in VistaGeometry). Supports alpha values and different formats, as well as mor operators etc. For now, only the class has changed - VistaCoreLibs functionality currently does not examine the alpha value (e.g. when setting a geometry's vertex colors) - this functionality will be added in the future. For now, to replaceing VistaColorRGB with VistaColor will result in the same behavior.
  - ADD: VistaBase/VistaColor
  - REM: VistaColorRGB (in VistaGeometry.h)**

 - FIX: VdfnThresholdNode absolute value check

 - FIX: VistaDfnViewerSourceNode now parses initial state

 - **ADD: model optimizer**

 - FIX: usage of wrong name for retreaval of chai3d transcodes
 - FIX: bug which occured in case not the right device was found

 - **ADD: Class for visualization of open gl primitives, e.g., lines, points. Similar to VistaOpenGLPolyLine, but supporting more primitives.**

 - FIX: missing variable initialization in DfnWindowSourceNode

 - **Added methods to print state of VdfnNodes/VfnGraphs for DebuggingPurposes. It can either be output manually upon a key trigger, or automatically on each update. Output can be redirected to any standard stream, a text file, or a dotty graph.
 These options are configured per InteractionContext  Context's section of the ini file
   - AUTODEBUG [bool] if true, the context's debug info will be printed after every Update
   - DEBUGTRIGGER [char] key binding for manual triggering of debug output
   - DEBUGSTREAM: either a standard stream (vstr::out, vstr::warn, vstr::err, cout, clog, cerr), a valid filename, or dot. If dot is specified, the context is dumped in the format "RoleName_Data.dot"**
  - APICHG: VdfnPortFactory::CPortAccess now also takes Port-To-String fuctor
  - APIADD: PrintInfo() function for VdfnNode and VdfnGraph 
  - APIADD: VistaInteractionContext API for Debugging 
  - STYLE: simplified adding default-style Port- and FunctorAccess in VdfnUtil

 - FIX: Win32ThreadImp::GetThreadId working with windows 5.2 and below

 - VistaSystem:
  - UPD: if plugin reports a name different to the requested name, a warnign is emitted, but the plugin is still accepted
  - FIX: explicitely set driver and transcoder plugin names correctly extracted now

 - CMake-Build
  - UPD: changed VISTACORELIBS_LIBRARIES order (for correct static linkage)
  - FIX: msvc projs also exported when no specific component is requested

 - VistaFileSystemNode (VistaTools):
  - FIX: extraction of file/dir-name from full path with backslashes

 - VrpnDriverPlugin:
  - FIX: Corrected DeviceClassName

 - ADD: dfn node for converting VistaTransformMatrix to std::string

 - VistaVector3D( VistaBase):
   - **APIADD: Set/GetValues with multiple float/double params**
   - FIX: VistaVector3D now also copies w-component on operator=



 - ** Mergeback of EXTERNAL_TRANSCODES branch 11/10/29 svn-rev 23946**
 
  - **Cluster:
  Created a common base class for all ClusterModes, and implementations for Standalone and Master/Server,
  which replace the old use of ClusterAux and Master/Slave-specific classes.
  All functionality should be achieved over the abstract API (e.g. to check if one is master or standalone,
  dont compare the clustertype anymore, but check GetIsLeader().
  Information about other cluster nodes is available over the new interface.
  Also manages creation of additional connections, DataTunnels, or NetworkSyncs - for this, the Slave should
  be given a range of free ports via the new ini key FREEPORTS. **
   - **UPD: ClusterSlaves now have timeout on broadcast-sync-read (configurable by SYNCTIMEOUT ini entry, in ms)  **
   - **MOVE: Moved Clusterstuff (ClusterModes, DataTunnel, NetworkSyncImps) to VistaKernel/Cluster**
   - **APIADD: ClusterMode allows construction of new connections/DataTunnels/NetworkSyncs**
   - **ADD: Available ports for DataCTunnel/NetworkSync for slaves read from config file**
   - **APIREM: VistaDataTunnelFactory - job is done by ClusterMode now**
   - **APIREM: old VistaClusterClient and VistaClusterServer**
   - **UPD: VistaNetworkSync**

   
  - **VistaMainLoop:
  Main Application loop and event emitting was hidden in OpenSGSystemClassFactory, this was extracted to the new
  VistaMainLoop, controlling the event emitting, display updates, etc.
  It can also be replaced by a user-defined variant to alter the event flow or to add logging etc. **
   - **ADD: VistaFrameLoop**
   - **APIADD: VistaSystem::GetFrameLoop and VistaSystem::SetFrameLoop**
   - REM: event controlling from OpenSGSystemClassFactory

  - ** ConversionFunction (VistaAspects):
   Added new namespace VistaConversion, containing generic conversion functions **
   - **Provides templated FormString<> and ToString<> fucntions. These work for all basic types,
   all VistaMathTypes, and for all classes that have a operator<< resp. operator>> to a std::ostream.
   Furthermore, vectors, lists, and arrays of these types can be printed**
   - **ToString functions always succeed, FromString functions have three variants:**
     1. taking target as ref-param and returning bool to indicate result
     2. taking flag to determine how to react to conversion errors (ignore|print warning|throw exception)
     3. returning result, throws exception on error
   - **Extend by: implementing operator<< or operator>>, or by spezializing ToString and FromString templates
    (either globally for all in VistaConversion, or in separate local file)**
   - **GetTypeName to retrieve (demangled) name of a type**
   - **Generic ConvertType<From, To> function and corresponding function object**
   - **CreateInitializedDefaultObject returns T() for classes, and 0-initialized for base types**
   - **To replace VistaAscpectsConversionUtils**
   - **Can be expanded to custom types by either defining std::ostream-operator<< and >>, or
   by creating a template specialization**

  - **VistaPropertyList (VistaAspects):
  Reworked API away from GetTheProperty* to more generic templated GetValue<> and SetValue<> (similar to new VistaConversion).
  This allows easier setting or getting of more complex datatypes (Arrays, VistaVector3Ds, etc.)
  It now  also properly handles errors by returning bool on GetValue  - No more use of global (and changeable) Nil-property**
   - **UPD: Throw exception when property-to-value conversion fails**
   - **UPD: GetProperty[Copy|Ref|ConstRef]() and GetSublist[Copy|Ref|ConstRef]() throws exception when property doesn't exist**
   - **APICHG: GetProperty --> GetPropertyCopy**
   - **APICHG: GetSublist --> GetSublistCopy**

  - **VistaIniFileParser (VistaTools):
  Added IniFileParser to replace VistaProfiler - it reads/writes ini files in the same format,
  but parses the whole file into a VistaPropertyList (or writes a file from one).
  Now also supports sub-sections (-> sub-proplists) in the ini-file **


  - **VistaReflectionable:
  VistaReflectionable PropertySet/Get templates generally use VistaConversion functions (no more Convert-functor)
  Before, set-functors required an explicit conversion function pointer, get-functors didn't.
  Now, the generic ones use VistaConversion by default, while TVistaPropertyConvertAnd[G|S]et can be used to provide
  custom ones.
  As a consequence, the VistaPropertySet will no longer require the ConversionFunction pointer as ctor paramter,
  and custom versions (e.g. to get/set a VistaVector3D) can be turned to generic setter/getter since VistaConversion
  now also supports containers and math types.**
   - **APICHG: renamed to be more consisten:**
     - **VistaGetArrayPropertyFunctor --> TVistaPropertyArrayGet**
     - **VistaSetArrayPropertyFunctor --> TVistaPropertyArraySet**
     - **VistaPropertyListGetFunctor --> TVistaPropertyListGet**
     - **VistaPropertyListSetFunctor --> TVistaPropertyListSet**
   - **APIADD: TVistaPropertyArraySet now accepts both functors with const array and non-const array params**
   - **APICHG: some const-correctness**


  - VistaStreams:
   - APIREM: lib-wise outstreams were removed
   - **ADD: functions and manipulators for stream indentation**
   - **ADD: functions and manipulators for standardized warning and error prefixes**
   - **APIADD/CHG: general stream API**
   - **MOVE: VistaStreams moved from VistaBase to VistaTools**
   - **CHG: VistaNullStream now local imp of VistaStreamUtils (use vstr::GetNullStream())**
   - **D: function VistaStreams::MakeStreamThreadSafe to make arbitrary outstream threadsafe
   and to allow cross-thread output without message fragmentation**
   
  - **RENAME: ini-entries DUMPGRAPHS -> DUMPDFNGRAPHS and WRITEPORTS -> WRITEDFNPORTS**
  - **RENAME: DFN DriverSensorNode's parameters sensor -> sensor_index and sensor_id -> sensor_name**
  

  - VistaPickManager
   - **REM: removed VistaPickManager (and its events)**

     
  - Vista(De)Serializer (InterProcComm):
   - **APIREM: Read*Name and Write*Name Api**
   

  - VistaInterProcComm/VistaNetDataCollector:
   - APIADD: Interface for direct passing of established connection

  - VistaInterProcComm/VistaNetDataDispatcher:
   - APIADD: Interface for direct passing of established connection
	

  - VistaThread (InterProcComm) and implementations:
   - **APIADD: static VistaThread::GetCallingThreadIdentity()**

  - VistaConnection (InterProcComm):
   - **APIADD: VistaConnection::SetReadTimeout to define default timeout when using ReadXYZ API (before: always read without timeout)**  

  - Added some google tests
	
  - DriverWindowAspect (VistaDeviceDrivers/VistaKernel):
  Formerly, there was an abstract window aspect in VistaDeviceDrivers, and a Kernel-specialized one in VistaKernel, adding an
  unnecessary dependency to the Kernel to these Drivers. This was changed by storing the OS-window-handle directly in the 
  WindowHandle, so only filling it is implementation-specific
   - REM: VistaDriverWindowAspect - Kernel-specific version now fully replaced by AbstractWindowAspect
   - APICHG: VistaAbstractWindowHandle now accepts WIndowHandles by const ref, not by pointer, stores them as copy internally
     
  - VistaDisplayBridge (VistaKernel):
   - APIREM: Obsolete (duplicate) CreateDisplaySystemsFromIni
   - CHG: moved framerate display overlay from GraphicsManager to DisplayManager (thus, no more DispMgr dependency on GrMgr) 
   - APICHG: AddSceneOverlay and RemSceneOverlay now take Viewport pointer instead of name
 
  - VistaDisplayManager (VistaKernel):
   - APICHG: CreateVistaWindow now takes ConfigName+Proplist instead of display and proplist
   - CHG: VistaWindow now sets section name as default (not name + pointer)  
   - STYLE: avoiding warnings from SetPropertyByList in display setup
   - APIADD: AddSceneOverlay and RemSceneOverlay with Viewport pointer instead of name
   - **APICHG: Add2D[Text|Bitmap|Line|Rectangle] -> New[Text|Bitmap|Line|Rectangle]**
  
  - VistaWindow (VistaKernel):
   - **FIX: Reflectionable name changed from FULL_SCREEN to FULLSCREEN (as advertised in comments)**
   - APIADD: GetWindowId
   - REM: DrawBorder API - was not actually used

  - VistaDisplayEvent (VistaKernel):
   - **REM: VistaDisplayEvent - was not properly implemented anyways, use Observeable property of DisplayEntities instead**
   - **UPD: enhancing of DisplayEntities' Observer notification**
	
  - VistaSceneOverlays (VistaKernel):
   - **APICHG: ctors now require DisplayManager and either viewport or viewportname**
   - CHG: All overlays now register themselves on creation (no longer need user-call to VistaDisplayManager::AddSceneOverlay)
	
  - WindowingToolkit (VistaKernel):
   - MOVE: Moved VistaWindowingToolkit to DisplayManager
   - APICHG: Windowtoolkit now created and maintained by DisplayManager
   - APICHG: Reworked Interface of WindowingToolkit - now more abstract, less glut-based
   - APIADD: WindowingToolkit can now activate Stencil and Accumulation Buffer
   - UPD: runs without any window   
   
  - VistaSystem (VistaKernel):
   - FIX: absolute path comp now handles mixed / and \
  
  - VistaSG and Bridges (VistaKernel)
   - CHG: renamed VistaSG to VistaSceneGraph
   - **APICHG: LoadNode and variants have optional parameter bVerbose - toggles info output (defaults to false)**

  - VistaGraphicsManager:
   - **APICHG: Get/SetCullingState -> Get/SetFrustumCullingState**
	   
  - VistaKernel:
   - Updated internal initialization phase to use IniFileParser+PropertyList
   - structured VistaSystem a little better (more subroutines)   
   - STYLE: removed usages of GetVistaSystem singleton access in Corelibs  

  - VistaTransformMatrix (VistaMath):
   - **UPD: Changed internal storage to column-major**
   - **APICHG: operator[] returns VistaTransformMatrix::Row instead of float* (to wrap row-wise access to column-major data )**
   - **APIADD: float* GetData for direct access to internal storage**
   - **APIADD: operator( row, column )**

  - UPD: VistaTools are now dependent on VistaInterProcComm  

  - CHG: Moved WebInterface from Kernel to KernelOpenSG, removed ini entries
  
  - VistaSceneOverlay
   - **APICHG: now has two ctors: one taking DisplaySystem+Viewport name, one taking Viewport pointer**
   - **APIADD: purely virtual UpdateOnViewportChange for VistaSceneOverlay**
   - APIADD: access to attached viewport
   - ADD: SceneOverlay observes viewport, calls UpdateOnViewportChange
  
  - VistaSimpleTextOverlay:
  Vista3DTextOverlay:
  VistaVirtualConsole:
   - APICHG: adjusted ctors and viewportupdates to SceneOverlay changes
   - APICHG: removed unused size and AdjustmentFlags from VistaVirtualConsole ctor

  - FIX: VistaGroupNode::IsValidIndex index check


  - STYLE: warning-free build (msvc and gcc 3.1.5)
  - STYLE: removed all pragma warning(disable), or push-popped them
  - STYLE: enhanced VistaSystem initialization output
  - STYLE: some more styleguide conformity
  - STYLE: removed lots of warnings
  - STYLE: removed plenty of empty doxygen comments
  - STYLE: enhanced Vista initialization output


 - FIX: 64bit atomics did not work on 32bit-linux

 - FIX: OpenCVFaceTrackFriver runnng with OpenCV version 2.1

 - **ADD: VistaGenericFactory and VistaMarshalledObjectFactory**

 - FIX: VistaTransformMatrix::SetBasisMatrix( VistaQuaternion ) typo in identity matrix init

 - VistaDfn3DMouseTransformNode (VistaKernel):
  - FIX: works correctly with non-symmetric projections now

Re: [vistavrtoolkit-general] WG: Clustermode: slaves recieving socket errors

[Ingo A. <iar...@ya...>]

Hi,

since you operate on linux, can you try to run a client using valgrind 
and dump its log?

That would be very helpful.

Note that your error is very weird (for several reasons), it will be 
hard to reproduce it, if there is no obvious flaw (in code that we do 
not have/see).

Ingo.



Am 16.12.2011 11:21, schrieb Mat...@dl...:

> I will try to point it out without pasting a shipload of code here.

Re: [vistavrtoolkit-general] WG: Clustermode: slaves recieving socket errors

[<Mat...@dl...>]

Hi,
I will try to point it out without pasting a shipload of code here.

The Interaction is using a handler-class derived from the "IVistaInteractionHandlerBase" (as in the 12IntentionSelectDemo). The events are handled in the "HandleContextChange" function. Events that are handled by the "HandleGraphUpdate" are just set handled without performing anything.
No own events are created or handled, so the only handled source type of events are the "InteractionEvents" created by the DFN/interaction contexts.


The Interaction context is using a 6DOF input device (Flystick) and setting the transformation of it to a TransformNode.

When the event is handled the transformation of this node is read an saved to member variables(vector,quaternion). Based on the containing information a local member variable(double) is modified (adding a calculated value).
Using the member variable a rotation is calculated and a TransformNode (with a textured cone as child) recieves the new rotation. In addition the value of the member variable is set as a text to a VistaTextNode.

Each time an "InteractionEvent" occurs and is handled the double variable is modified and the new rotation of the TransformNode is calculated and set.




I hope this helps to understand the context. If you need more information feel free to ask for it.

Best regards
Matthias



Von: Dominik Rausch [mailto:ra...@vr...]
Gesendet: Donnerstag, 15. Dezember 2011 20:50
An: vis...@li...
Betreff: Re: [vistavrtoolkit-general] WG: Clustermode: slaves recieving socket errors

Hi

When yo say that your interaction isbased on events, do you mean native system events or external message events?
If the latter is the case, what is the size of these messages? If they are too big, the tcp stack buffer might be overrun.
Not sure if this can produce an EFAULT, however.
If you could provide some more information or a code sample, maybe we could try repoducing the issue.

Regards
  Dominik



Dipl.-Inform. Dominik Rausch



Virtual Reality Group, RWTH Aachen University

Lehrstuhl für Informatik 12 (Hochleistungsrechnen)



  Rechen- und Kommunikationszentrum

  Seffenter Weg 23, 52074 Aachen

  Tel. +49 241 80 29732

  ra...@vr...<mailto:ra...@vr...>

  www.vr.rwth-aachen.de<http://www.vr.rwth-aachen.de>

Am 15.12.2011 19:01, schrieb Mat...@dl...:<mailto:Mat...@dl...:>

The setup:
Clustermode, 1 Master, 3 Slaves. The connection between the Master and the Slaves does only rely on the Clustermode, i.e. there is no self-coded connection between them and no code relating connections at all. The interaction is based on events and each slave is interpreting the events hisself (reading values from the SG, doing some calculations, changing values on the SG).
This works fine and is also in sync.

The problem:
While using the setup, the Slaves sometimes get a Socket-error and close their application. This happens independent for each Slave and also independent of the time or number of events. The master does not crash in this way at any time.
The errormessage is printed after the Slave has finished his interpretation of the event (he is not doing his fancy stuff anymore).
The only way to reproduce it is to interact and wait until the problem occurs. Sometimes it happens fast, sometimes it takes a longer period of time.

The error message:

[EFAULT] The socket structure  address  is  outside  the  user's  addressspace.
VistaTCPSocket[690df0]::CloseSocket(0)
VistaExceptionBase() -- Exception [258]
===============================================
IVistaSocket::ReceiveRaw -- Exception
===============================================
Location: /research/modules/installs/ViSTA/ViSTA-1.12.0-debug/SETUP/VistaCoreLibs/VistaInterProcComm/IPNet/VistaSocket.cpp
Line:     1085
===============================================

VistaExceptionBase() -- Exception [258]
===============================================
IVistaSocket::ReceiveRaw -- Exception
===============================================
Location: /research/modules/installs/ViSTA/ViSTA-1.12.0-debug/SETUP/VistaCoreLibs/VistaInterProcComm/IPNet/VistaSocket.cpp
Line:     1085
===============================================


I have already tried removing all the dynamic generated Variables and replacing them with private members of the class they are in. (avoid memory leaks or something like this)
-> did not have any result





Have you any suggestions to solve this problem?

Thanks for your help.

Best regards
Matthias

Re: [vistavrtoolkit-general] WG: Clustermode: slaves recieving socket errors

[Dominik R. <ra...@vr...>]

Hi

When yo say that your interaction isbased on events, do you mean native 
system events or external message events?
If the latter is the case, what is the size of these messages? If they 
are too big, the tcp stack buffer might be overrun.
Not sure if this can produce an EFAULT, however.
If you could provide some more information or a code sample, maybe we 
could try repoducing the issue.

Regards
   Dominik

Dipl.-Inform. Dominik Rausch

Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)

   Rechen- und Kommunikationszentrum
   Seffenter Weg 23, 52074 Aachen
   Tel. +49 241 80 29732
   ra...@vr...
   www.vr.rwth-aachen.de


Am 15.12.2011 19:01, schrieb Mat...@dl...:
>
> The setup:
> Clustermode, 1 Master, 3 Slaves. The connection between the Master and 
> the Slaves does only rely on the Clustermode, i.e. there is no 
> self-coded connection between them and no code relating connections at 
> all. The interaction is based on events and each slave is interpreting 
> the events hisself (reading values from the SG, doing some 
> calculations, changing values on the SG).
> This works fine and is also in sync.
>
> The problem:
> While using the setup, the Slaves sometimes get a Socket-error and 
> close their application. This happens independent for each Slave and 
> also independent of the time or number of events. The master does not 
> crash in this way at any time.
> The errormessage is printed after the Slave has finished his 
> interpretation of the event (he is not doing his fancy stuff anymore).
> The only way to reproduce it is to interact and wait until the problem 
> occurs. Sometimes it happens fast, sometimes it takes a longer period 
> of time.
>
> The error message:
>
> [EFAULT] The socket structure  address  is  outside  the  user's  
> addressspace.
> VistaTCPSocket[690df0]::CloseSocket(0)
> VistaExceptionBase() -- Exception [258]
> ===============================================
> IVistaSocket::ReceiveRaw -- Exception
> ===============================================
> Location: 
> /research/modules/installs/ViSTA/ViSTA-1.12.0-debug/SETUP/VistaCoreLibs/VistaInterProcComm/IPNet/VistaSocket.cpp
> Line:     1085
> ===============================================
>
> VistaExceptionBase() -- Exception [258]
> ===============================================
> IVistaSocket::ReceiveRaw -- Exception
> ===============================================
> Location: 
> /research/modules/installs/ViSTA/ViSTA-1.12.0-debug/SETUP/VistaCoreLibs/VistaInterProcComm/IPNet/VistaSocket.cpp
> Line:     1085
> ===============================================
>
>
> I have already tried removing all the dynamic generated Variables and 
> replacing them with private members of the class they are in. (avoid 
> memory leaks or something like this)
> -> did not have any result
>
>
>
>
>
> Have you any suggestions to solve this problem?
>
> Thanks for your help.
>
> Best regards
> Matthias

[vistavrtoolkit-general] WG: Clustermode: slaves recieving socket errors

[<Mat...@dl...>]

forgot a "t" in the adress
________________________________
Von: Schneider, Matthias
Gesendet: Donnerstag, 15. Dezember 2011 18:59
Bis: vis...@li...; vis...@li...
Betreff: Clustermode: slaves recieving socket errors

Hi all,
at first I want to thank you for the help you gave me last time.
Therefore i hope you can help me another time.

The setup:
Clustermode, 1 Master, 3 Slaves. The connection between the Master and the Slaves does only rely on the Clustermode, i.e. there is no self-coded connection between them and no code relating connections at all. The interaction is based on events and each slave is interpreting the events hisself (reading values from the SG, doing some calculations, changing values on the SG).
This works fine and is also in sync.

The problem:
While using the setup, the Slaves sometimes get a Socket-error and close their application. This happens independent for each Slave and also independent of the time or number of events. The master does not crash in this way at any time.
The errormessage is printed after the Slave has finished his interpretation of the event (he is not doing his fancy stuff anymore).
The only way to reproduce it is to interact and wait until the problem occurs. Sometimes it happens fast, sometimes it takes a longer period of time.

The error message:

[EFAULT] The socket structure  address  is  outside  the  user's  addressspace.
VistaTCPSocket[690df0]::CloseSocket(0)
VistaExceptionBase() -- Exception [258]
===============================================
IVistaSocket::ReceiveRaw -- Exception
===============================================
Location: /research/modules/installs/ViSTA/ViSTA-1.12.0-debug/SETUP/VistaCoreLibs/VistaInterProcComm/IPNet/VistaSocket.cpp
Line:     1085
===============================================

VistaExceptionBase() -- Exception [258]
===============================================
IVistaSocket::ReceiveRaw -- Exception
===============================================
Location: /research/modules/installs/ViSTA/ViSTA-1.12.0-debug/SETUP/VistaCoreLibs/VistaInterProcComm/IPNet/VistaSocket.cpp
Line:     1085
===============================================


I have already tried removing all the dynamic generated Variables and replacing them with private members of the class they are in. (avoid memory leaks or something like this)
-> did not have any result





Have you any suggestions to solve this problem?

Thanks for your help.

Best regards
Matthias

[vistavrtoolkit-general] Fwd: Re: Problem with VistaMsgChannel - performing to slow

[Dominik R. <ra...@vr...>]

Hi

I forgot to reply to the lists, so here a Fwd of my reply.

Regards
   Dominik

-------- Original-Nachricht --------
Betreff: 	Re: [vistavrtoolkit-general] Problem with VistaMsgChannel - 
performing to slow
Datum: 	Wed, 07 Dec 2011 21:34:13 +0100
Von: 	Dominik Rausch <ra...@vr...>
An: 	Mat...@dl...



Hi

The concept you used is mostly suited for communication of external 
applications with the Vista application, as is done in the AliceBobDemo.
When trying to distribute events in cluster mode, there are better 
alternatives (especially since one usually only wants to send data to 
the slaves, but not receive answers).
Depending on your application, you have different options:

Directly use the MsgPort provided by the VistaSystem (as shown in the 
AliceBobDemo) to send external events to the Vista-App, which triggers 
an event on both master and slaves.
However, if I understand you correctly, you want to trigger the actions 
from within the main vista app.

You can emit your own VistaExternalMsgEvent, which is then not only 
Handled on the master, but also transmitted and processed on the clients.
Just create one and set a VistaMsg with a Custom MsgTicket, and do the 
processing in the VistaEventHandler::HandleEvent callback.
This is probably the easiest way to go, but has one drawback: there may 
be ordering issues when emitting the ExternalMsgEvent from a 
SystemEvent-callback, since on the master the event is emitted and 
handled immediately, but on the slaves this happens after the system 
event that is currently being processed. Keep that in mind, and try to 
emit the event right in the end of your custom SystemEvent-Handling

You could also use the DataTunnels and use DataLaVista to sync the data 
- however, this is probably a little overkill. Plus, I'm not too 
familiar with DLV, so I can't help you much here.

Another alternative was added with the recent merge-back of the 
CLUSTERMODE_TEST branch (not in 1.12, but in trunk).
It allows to request a VistaNetworkSync object from the ClusterMode, 
which allows syncing data (i.e. transmitting it to from master to 
slaves) in a way that you don't have to care about cluster layout etc.

Hope this helps :)
Regards
   Dominik


Dipl.-Inform. Dominik Rausch

Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)

   Rechen- und Kommunikationszentrum
   Seffenter Weg 23, 52074 Aachen
   Tel. +49 241 80 29732
   ra...@vr...
   www.vr.rwth-aachen.de


Am 07.12.2011 19:06, schrieb Mat...@dl...:
> Hi all,
>
> I encountered a Problem regarding the TCP connection.
>
> I am using Vista 1.12.0 from the tag.
>
> My intention is to create a master/slave setup where the Master is 
> sending data to the slave via TCP.
>
> The Master is establishing a TCP connection using the 
> "VistaConnectionIP" and using a "VistaMessageChannel" with this 
> connection to transfer the data to the slave.
> The Data is written in a "VistaPropertyList" and transfered using the 
> "WriteMsg (int iMethodToken, const VistaPropertyList 
> &rList,VistaPropertyList &rAnswer)" method.
> The order to send the Data is triggered by an InteractionEvent on the 
> Master's input devices (60+ events/second).
>
> The Slave on the other hand is using the MSGPORT to enable the master 
> to connect to him. The messages ( VistaCommandEvent's) are parsed by a 
> Class the is derived from the "VistaEventHandler".
>
> The communication struct is based on the VistaDemo 17 (Alice, Bob).
>
>
> The problem:
>
> The master is blocked by the "WriteMsg" method. Without this messaging 
> the master uses to have ~160 frames per second, but when the Messaging 
> is enabled this is reduced to 10 for 1 slave, 5 for 2 slaves and 3.3 
> for 3 slaves. Therefore the Slaves also receive the reduced amount of 
> events.
>
> I have already tried the following things:
>
> - Disable the blocking of the connection:
> This has lead to the slaves getting only 5 Events and then releasing 
> the port, so that the connection collapsed. The master went back to 
> ~160 frames/second, but the slave did not receive any more messages.
>
> - Disabled setting the answer of the slave
> Did not chance anything.
>
>
> Have you any suggestions to avoid this performance loss?
>
> Thanks for your help.
>
> Best regards
> Matthias
>
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
>
>
> _______________________________________________
> vistavrtoolkit-general mailing list
> vis...@li...
> https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general

Re: [vistavrtoolkit-general] Problem with VistaMsgChannel - performing to slow

[Ingo A. <iar...@ya...>]

Matthias!

Blocking sending data over the TCP line will stall you application
performance, of course. This is by principle a problem of TCP communication.

Some information is missing from your mail:

* what is the size of your data? small (<1k) or large (>64k)?
* what is your connection type/bandwith/round trip time/MTU?
* is your master producing a packet per iteration (er even many)?

Depending on your specific setup, it might become clear that you just
want to send more over the TCP line than what you can.

Some things you could do:

* use a thread to dispatch the packets blocking to the TCP line. I
would, however, think that this will not help much, as it will just keep
your master producing and all data will be queued in the send thread
instead. You can use a simple thread for that or one of the DLV
components in the IPC (if you do not plan to transform some of your data
this might be overkill, though the handshake in DLV is quite
thread-friendly)

* collapse some/many smaller packets into a larger one on application
level. Too large will not help

* send non-blocking, but keep looking at the return value of
VistaConnection::WaitForSendFinish() now and then. This will ensure that
your connection will not be flooded (this is what you report in your
mail: depending on the OS, when using async transfer and you just put in
too many packets, the connection will be dropped (windows is/was
especially shaky here). Note that the call to this method is blocking,
so it can wait for all data to be transferred, which might not be what
you want.

* you could fiddle around with the VistaSocket API to set the
send/receive buffer size, but if you are using modern OSes, I do not
recommend that. The OS nowadays do a pretty good job here.

* use more than one MsgChannel and send the packets in an application
defined order over each line. Of course you will need another mechanism
to ensure the order of receival on the slave side.

* also, if you are sending to more than one slave, you transfer the same
data more than once. A remedy could be to use some kind of reliable
multicast or likely.

However, without a more specific outline of your setup/needs, this is
all just guessing.

Hope it helps a bit,

Ingo.



On 12/07/2011 07:06 PM, Mat...@dl... wrote:
> Hi all,
> 
> I encountered a Problem regarding the TCP connection.
> 
> I am using Vista 1.12.0 from the tag.
> 
> My intention is to create a master/slave setup where the Master is
> sending data to the slave via TCP.
> 
> The Master is establishing a TCP connection using the
> "VistaConnectionIP" and using a "VistaMessageChannel" with this
> connection to transfer the data to the slave.
> The Data is written in a "VistaPropertyList" and transfered using the
> "WriteMsg (int iMethodToken, const VistaPropertyList
> &rList,VistaPropertyList &rAnswer)" method.
> The order to send the Data is triggered by an InteractionEvent on the
> Master's input devices (60+ events/second).
> 
> The Slave on the other hand is using the MSGPORT to enable the master to
> connect to him. The messages ( VistaCommandEvent's) are parsed by a
> Class the is derived from the "VistaEventHandler".
> 
> The communication struct is based on the VistaDemo 17 (Alice, Bob).
> 
> 
> The problem:
> 
> The master is blocked by the "WriteMsg" method. Without this messaging
> the master uses to have ~160 frames per second, but when the Messaging
> is enabled this is reduced to 10 for 1 slave, 5 for 2 slaves and 3.3 for
> 3 slaves. Therefore the Slaves also receive the reduced amount of events.
> 
> I have already tried the following things:
> 
> - Disable the blocking of the connection:
> This has lead to the slaves getting only 5 Events and then releasing the
> port, so that the connection collapsed. The master went back to ~160
> frames/second, but the slave did not receive any more messages.
> 
> - Disabled setting the answer of the slave
> Did not chance anything.
> 
> 
> Have you any suggestions to avoid this performance loss?
> 
> Thanks for your help.
> 
> Best regards
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> 
> 
> 
> _______________________________________________
> vistavrtoolkit-general mailing list
> vis...@li...
> https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general

[vistavrtoolkit-general] Problem with VistaMsgChannel - performing to slow

[<Mat...@dl...>]

Hi all,

I encountered a Problem regarding the TCP connection.

I am using Vista 1.12.0 from the tag.

My intention is to create a master/slave setup where the Master is sending data to the slave via TCP.

The Master is establishing a TCP connection using the "VistaConnectionIP" and using a "VistaMessageChannel" with this connection to transfer the data to the slave.
The Data is written in a "VistaPropertyList" and transfered using the "WriteMsg (int iMethodToken, const VistaPropertyList &rList,VistaPropertyList &rAnswer)" method.
The order to send the Data is triggered by an InteractionEvent on the Master's input devices (60+ events/second).

The Slave on the other hand is using the MSGPORT to enable the master to connect to him. The messages ( VistaCommandEvent's) are parsed by a Class the is derived from the "VistaEventHandler".

The communication struct is based on the VistaDemo 17 (Alice, Bob).


The problem:

The master is blocked by the "WriteMsg" method. Without this messaging the master uses to have ~160 frames per second, but when the Messaging is enabled this is reduced to 10 for 1 slave, 5 for 2 slaves and 3.3 for 3 slaves. Therefore the Slaves also receive the reduced amount of events.

I have already tried the following things:

- Disable the blocking of the connection:
This has lead to the slaves getting only 5 Events and then releasing the port, so that the connection collapsed. The master went back to ~160 frames/second, but the slave did not receive any more messages.

- Disabled setting the answer of the slave
Did not chance anything.


Have you any suggestions to avoid this performance loss?

Thanks for your help.

Best regards
Matthias

Re: [vistavrtoolkit-general] Different behavior for empty parameterlist for ViSTA Apps.

[Gerrit G. <Gar...@vr...>]

hey patric,

thank you for your reply. You're right, that the string is not in the
vista kernel. This behavior is implemented in the VisaApp., my fault
was to look at the wrong tab to get the filename ;) Nevertheless this
behavior is strange and I gonna fix this at the VisaApplication.

Best regards,
Gerrit

--
Gerrit Garbereder B.Sc.
Mathematisch-technischer Softwareentwickler

RWTH Aachen University, Center for Computing and Communication
Rechen- und Kommunikationszentrum
Virtual Reality Group
Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
Raum 108
Tel.: +49 (0) 241 80-29731
mailto:gar...@vr...
URL: www.vr.rwth-aachen.de





On Wed, Nov 30, 2011 at 16:33, Patric Schmitz <sc...@vr...> wrote:
> On Wed, 30 Nov 2011 16:17:34 +0100
> Gerrit Garbereder <Gar...@vr...> wrote:
>
>> Hey folks,
>>
>> we are using custom commandline args in the VisaApp. I've got in
>> trouble with the commandline args because I had a typo in the
>> commandline args which caused the VistaSystem to set vista.ini as
>> displayini file. But when I use all commanline args correctly they get
>> parsed out of the argv vector by the VisaApplication and the default
>> for the empty parameterlist in VistaSystem is, that the displayini
>> file is vista_display.ini.
>>
>> In my eyes this behavior is very confusing cause I would expect, the
>> same default values independent from what I enter in the commandline -
>> except when I give an explicit value.
>>
>> What do you think about this behavior?
>
> Hi Gerrit,
>
> the behavior you observe should have nothing to do with a default value
> assumed by ViSTA (the string "vista_display.ini" is not contained in
> the kernel sources at all). Could you post the contents of the
> vista.ini file you are actually using? Could it be that in there, you
> have something like
> [SYSTEM]
> DISPLAYINI = vista_display.ini ?
>
> Also, please post the relevant code lines from VisaApplication which
> parse out of the argv vector and call VistaSystem::Init().
>
> Regards,
> Patric
>
> --
> Patric Schmitz, MaTA, B.Sc.
>
> Virtual Reality Group, RWTH Aachen University
> Lehrstuhl für Informatik 12 (Hochleistungsrechnen)
>
> Immersive Visualization Services
>
>  Rechen- und Kommunikationszentrum
>  Seffenter Weg 23, 52074 Aachen
>  Tel. +49 241 80-24893
>  Email sc...@vr...
>  URL www.vr.rwth-aachen.de
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> vistavrtoolkit-general mailing list
> vis...@li...
> https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general

Re: [vistavrtoolkit-general] Different behavior for empty parameterlist for ViSTA Apps.

[Patric S. <sc...@vr...>]

On Wed, 30 Nov 2011 16:17:34 +0100
Gerrit Garbereder <Gar...@vr...> wrote:

> Hey folks,
> 
> we are using custom commandline args in the VisaApp. I've got in
> trouble with the commandline args because I had a typo in the
> commandline args which caused the VistaSystem to set vista.ini as
> displayini file. But when I use all commanline args correctly they get
> parsed out of the argv vector by the VisaApplication and the default
> for the empty parameterlist in VistaSystem is, that the displayini
> file is vista_display.ini.
> 
> In my eyes this behavior is very confusing cause I would expect, the
> same default values independent from what I enter in the commandline -
> except when I give an explicit value.
> 
> What do you think about this behavior?

Hi Gerrit,

the behavior you observe should have nothing to do with a default value
assumed by ViSTA (the string "vista_display.ini" is not contained in
the kernel sources at all). Could you post the contents of the
vista.ini file you are actually using? Could it be that in there, you
have something like
[SYSTEM]
DISPLAYINI = vista_display.ini ?

Also, please post the relevant code lines from VisaApplication which
parse out of the argv vector and call VistaSystem::Init().

Regards,
Patric

-- 
Patric Schmitz, MaTA, B.Sc.

Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)

Immersive Visualization Services

  Rechen- und Kommunikationszentrum
  Seffenter Weg 23, 52074 Aachen
  Tel. +49 241 80-24893
  Email sc...@vr...
  URL www.vr.rwth-aachen.de

[vistavrtoolkit-general] Different behavior for empty parameterlist for ViSTA Apps.

[Gerrit G. <Gar...@vr...>]

Hey folks,

we are using custom commandline args in the VisaApp. I've got in
trouble with the commandline args because I had a typo in the
commandline args which caused the VistaSystem to set vista.ini as
displayini file. But when I use all commanline args correctly they get
parsed out of the argv vector by the VisaApplication and the default
for the empty parameterlist in VistaSystem is, that the displayini
file is vista_display.ini.

In my eyes this behavior is very confusing cause I would expect, the
same default values independent from what I enter in the commandline -
except when I give an explicit value.

What do you think about this behavior?

Best regards,
Gerrit

--
Gerrit Garbereder B.Sc.
Mathematisch-technischer Softwareentwickler

RWTH Aachen University, Center for Computing and Communication
Rechen- und Kommunikationszentrum
Virtual Reality Group
Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
Raum 108
Tel.: +49 (0) 241 80-29731
mailto:gar...@vr...
URL: www.vr.rwth-aachen.de

Re: [vistavrtoolkit-general] ReshapeFunctor

[Dominik R. <ra...@vr...>]

Hi

The reshaping of windows is no longer handled by the 
OpenSG-Implementation, since it is a responsibility of the 
WindowingToolkit, and has no dependency on OpenSG.
Thus, the window reshape is interpreted by the WindowingToolkit 
directly, and triggers a notify about the resize on the Window.
Since OpenSG needs info about the resize, it observes for window resizes 
and tells OpenSG about it.
This should make the separation of OpenSG and the WindowingToolkit a 
little more distinct.

Regards
   Dominik

--

Dipl.-Inform. Dominik Rausch

Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)

   Rechen- und Kommunikationszentrum
   Seffenter Weg 23, 52074 Aachen
   Tel. +49 241 80 29732
   ra...@vr...
   www.vr.rwth-aachen.de


Am 10.11.2011 15:40, schrieb Gerrit Garbereder:
> Hey folks,
>
> during the migration of our application on the current ViSTA trunk
> I've noticed that no functor is set as OpenSG's ReshapeFunctor.
> In older ViSTA Versions was an event fired, when the window size was changed.
>
> Is it in ViSTA 1.11 and newer not provided to handle window size changes?
>
> Best regards,
> Gerrit
>
> --
> Gerrit Garbereder B.Sc.
> Mathematisch-technischer Softwareentwickler
>
> RWTH Aachen University, Center for Computing and Communication
> Rechen- und Kommunikationszentrum
> Virtual Reality Group
> Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
> Raum 108
> Tel.: +49 (0) 241 80-29731
> mailto:gar...@vr...
> URL: www.vr.rwth-aachen.de
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> vistavrtoolkit-general mailing list
> vis...@li...
> https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general

[vistavrtoolkit-general] ReshapeFunctor

[Gerrit G. <Gar...@vr...>]

Hey folks,

during the migration of our application on the current ViSTA trunk
I've noticed that no functor is set as OpenSG's ReshapeFunctor.
In older ViSTA Versions was an event fired, when the window size was changed.

Is it in ViSTA 1.11 and newer not provided to handle window size changes?

Best regards,
Gerrit

--
Gerrit Garbereder B.Sc.
Mathematisch-technischer Softwareentwickler

RWTH Aachen University, Center for Computing and Communication
Rechen- und Kommunikationszentrum
Virtual Reality Group
Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
Raum 108
Tel.: +49 (0) 241 80-29731
mailto:gar...@vr...
URL: www.vr.rwth-aachen.de

Re: [vistavrtoolkit-general] ConversionScript

[Gerrit G. <Gar...@vr...>]

Hi Dominic,

I've tried your suggestion in line 70 and 87 but it ends up with the
same error.

Regards,
Gerrit

--
Gerrit Garbereder B.Sc.
Mathematisch-technischer Softwareentwickler

RWTH Aachen University, Center for Computing and Communication
Rechen- und Kommunikationszentrum
Virtual Reality Group
Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
Raum 108
Tel.: +49 (0) 241 80-29731
mailto:gar...@vr...
URL: www.vr.rwth-aachen.de



On Tue, Nov 8, 2011 at 14:15, Dominik Rausch <ra...@vr...> wrote:
> Hi
>
> It seems as if the file has  a different encoding than guessed by python.
> Try
>        outFile = open( file, 'r+', encoding='utf-8' )
> instead of
>        outFile = open( file, 'r+' )
>
> Regards
>  Dominik
>
> --
>
> Dipl.-Inform. Dominik Rausch
>
> Virtual Reality Group, RWTH Aachen University
> Lehrstuhl für Informatik 12 (Hochleistungsrechnen)
>
>  Rechen- und Kommunikationszentrum
>  Seffenter Weg 23, 52074 Aachen
>  Tel. +49 241 80 29732
>  ra...@vr...
>  www.vr.rwth-aachen.de
>
>>-----Original Message-----
>>From: Gerrit Garbereder [mailto:Gar...@vr...]
>>Sent: Tuesday, November 08, 2011 1:34 PM
>>To: vis...@li...
>>Subject: [vistavrtoolkit-general] ConversionScript
>>
>>Hi,
>>
>>i've just updated to ViSTA trunk and would like to convert our code
>>via the ConversionScripts. Unfortunately I end up with the following
>>error:
>>
>>C:\Users\Gerrit\work\contrib\ConversionScripts>c:\Python32\python.exe
>>VistaToTrunk.py c:\Users\Gerrit\work\VisaApplication\trunk
>>startdir: c:\Users\Gerrit\work\VisaApplication\trunk
>>Traceback (most recent call last):
>>  File "VistaToTrunk.py", line 129, in <module>
>>    ProcessFiles( root, files )
>>  File "VistaToTrunk.py", line 103, in ProcessFiles
>>    ReplaceContent( fullName, tuple[1] )
>>  File "VistaToTrunk.py", line 71, in ReplaceContent
>>    filecontent = input.read()
>>  File "c:\Python32\lib\encodings\cp1252.py", line 23, in decode
>>    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
>>UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position
>>1155: character maps to <undefined>
>>
>>Can someone help me to use the script?
>>I'm using Python 3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64
>>bit (AMD64)]
>>
>>Best regards,
>>Gerrit
>>
>>--
>>Gerrit Garbereder B.Sc.
>>Mathematisch-technischer Softwareentwickler
>>
>>RWTH Aachen University, Center for Computing and Communication
>>Rechen- und Kommunikationszentrum
>>Virtual Reality Group
>>Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
>>Raum 108
>>Tel.: +49 (0) 241 80-29731
>>mailto:gar...@vr...
>>URL: www.vr.rwth-aachen.de
>>
>>------------------------------------------------------------------------
>>------
>>RSA(R) Conference 2012
>>Save $700 by Nov 18
>>Register now
>>http://p.sf.net/sfu/rsa-sfdev2dev1
>>_______________________________________________
>>vistavrtoolkit-general mailing list
>>vis...@li...
>>https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general
>
>

[vistavrtoolkit-general] ConversionScript

[Gerrit G. <Gar...@vr...>]

Hi,

i've just updated to ViSTA trunk and would like to convert our code
via the ConversionScripts. Unfortunately I end up with the following
error:

C:\Users\Gerrit\work\contrib\ConversionScripts>c:\Python32\python.exe
VistaToTrunk.py c:\Users\Gerrit\work\VisaApplication\trunk
startdir: c:\Users\Gerrit\work\VisaApplication\trunk
Traceback (most recent call last):
  File "VistaToTrunk.py", line 129, in <module>
    ProcessFiles( root, files )
  File "VistaToTrunk.py", line 103, in ProcessFiles
    ReplaceContent( fullName, tuple[1] )
  File "VistaToTrunk.py", line 71, in ReplaceContent
    filecontent = input.read()
  File "c:\Python32\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position
1155: character maps to <undefined>

Can someone help me to use the script?
I'm using Python 3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64
bit (AMD64)]

Best regards,
Gerrit

--
Gerrit Garbereder B.Sc.
Mathematisch-technischer Softwareentwickler

RWTH Aachen University, Center for Computing and Communication
Rechen- und Kommunikationszentrum
Virtual Reality Group
Dienstgebäude Kopernikusstraße 6, 52074 Aachen (Germany)
Raum 108
Tel.: +49 (0) 241 80-29731
mailto:gar...@vr...
URL: www.vr.rwth-aachen.de

[vistavrtoolkit-general] CLUSTERMODE_TEST branch merged back

[Dominik R. <ra...@vr...>]

Hi all

I merged back the CLUSTERMODE_TEST branch today, which added a bunch of 
changes to the CoreLibs.
Apart from some changes to the Clustermode, there are a lot of other 
modifications, too,
an extensive list can be found here: 
https://wiki.sistec.dlr.de/VistaCoreLibsVersionLog (important changes 
are bolded)

If you want to switch to the newest trunk, there are some API changes 
you'll need to incorporate.
The ConversionScript (in svn under 
projects/Vista/trunk/contrib/ConversionScripts/VistaToTrunk.py) should apply
many of the required API-changes (and differences in the ini files). 
However, some can't or shouldn't be performed automatically:

ClusterMode:
   All variants (Standalone, Master, Slave) are inherited from 
VistaClusterMode, giving a generic interface to get info about the cluster,
   e.g. number of nodes etc. There is now also API to check 
GetIsLeader() and GetIsFollower(), which replaces the former
   if( IsMaster() || IsServer() || IsStandalone() )
   Furthermore, they now work as factory for the DataTunnel and 
NetworkSync (the latter now having extended functionality). For this,
   a new ini entry (in the system section of clusterini) was added: 
FREEPORTS specifies a list of free ports on the node, which can be used 
to construct
   new connections to other nodes, e.g. for DataTunnels or custom use. 
syntax is a comma-separated list of either individual ports, or port 
ranges (e.g. 4242, 4244-4248, 10011-10025, 10028)

VistaPropertyList:
   The API changed from the Former fixed-type getter/setter to more 
vrsatile templated getter/setter, and also check if getting was successfull.
   Since it checks for both existance of the property and success of 
conversion to the desired value.
   Thus, it is possible to replace "Type GetThePropertyType( name )" by 
"Type GetValue<Type>( name )", however, this will by default print a 
warning.
   Alternatively, you can use  GetValueType( name, 
VistaConversion::ON_ERROR_DO_NOTHING ) or GetValueOrDefault<Type>( name 
) to receive the
   default-initialized value.
   The Setter-API is less problematic (setting values always succeed), 
but still you should check if it fits, since ypu can now, for example, 
set floats directly
   instead of using the bool setter (same is true for getters, of 
course). Furthermore, VistaVectorMathTypes and stl-containers are now 
natively supported, so
   you wont need to create temporary list<string>-values
   Additionally, when getting a sub-propertylist, you can now use 
GetSubList[Copy|Ref||ConstRef]. However, these do not - as was the case 
before - an
   empty proplist anymore if the subproplist doesn't exist, since the 
ref-versions pointed to a static proplist (which could potentially be 
modified).
   Thus, make sure to use HasSubList beforehand.
   If you still want to perform automatic replacements, the rules are in 
the ConversionScript, but commented out - add them when you want.

VistaReflectionable:
   Before, TVistaPropertySet required an explicit stringconversion 
function pointer, and TVistaProperGet didn't.
   Now, both by default use VistaConversion, and if you still need to 
provide a custom conversion, use TVistaPropertyConvertAnd[Get|Set].
   Since the pointer is now no longer in the API, it has to be removed 
from the ctor. This is hard to do reliably with automatic replacement,
   but if you want to try, here is a MSVC-regex that may work in most 
cases (use at your own risk):
   REPLACE ,[ \t]*\n*[ 
\t]*&VistaAspectsConversionStuff\:\:Convert(String)*To(String|Bool|Double|Int|String|Float|Float|2Float|3Float)(1|2|3|List)*[ 
]*\),
   WITH ),
   Also, setting/getting VistaVector3D and such can now be achieved 
without own conversion functions - you might want to replace these.

In VistaKernel, the DisplayOverlays are no longer first created and then 
added to a Viewport, instead, the Viewport (or DisplayManager and 
optional Viewport name)
   is passed to the ctor, which automatically handles registration. 
Furthermore, the interface was extended to allow enabling/disabling, and 
to forward viewport
   size changes to the Overlay.

Furthermore, both the VistaProfiler and the VistaAspectConversionUtils 
now have new versions (VistaIniFileParser and VistaConversion) to 
replace them.
While the old ones are still available, give the new ones a try, please.

These are the most visible changes to you, but there's a lot more 
(including many style stuff like removal of compiler warnings and 
enhanced Vista initialization output), if you want, check the version log.
And if you have feedback/suggestions, you're always welcome :)

Greets
   Dominik

-- 

Dipl.-Inform. Dominik Rausch

Virtual Reality Group, RWTH Aachen University
Lehrstuhl für Informatik 12 (Hochleistungsrechnen)

   Rechen- und Kommunikationszentrum
   Seffenter Weg 23, 52074 Aachen
   Tel. +49 241 80 29732
   ra...@vr...
   www.vr.rwth-aachen.de

[vistavrtoolkit-general] ViSTA release 1.12

[Dominik R. <ra...@vr...>]

import os, sys, shutil, re

cppreplaces = [
	( re.compile( r'(\s|\<|\(|\*)(microtime|systemtime|microstamp|sint32|uint32|ushort16|sshort16|float32|ubyte8|byte8|sint64|uint64|float64|val32|val64)(\W)', re.MULTILINE ), r'\1VistaType::\2\3' ),
	( re.compile( r'<VistaDeviceDriversBase/Vista([a-zA-Z]*)Aspect.h>', re.MULTILINE ), r'<VistaDeviceDriversBase/DriverAspects/Vista\1Aspect.h>' ),
]

xmlreplaces = [
]

inireplaces = [
	( re.compile( r'(TYPE\s*=\s*)(MOUSE\s|KEYBOARD\s)', re.MULTILINE ), r'\1GLUT\2' ),
	( re.compile( r'^(\s*)DRIVERPLUGINS(\s*=\s*)\S*(\s*)$', re.MULTILINE ), r'\1DRIVERPLUGINDIRS\2${VISTACORELIBS_DRIVER_PLUGIN_DIRS}\3' ),
	( re.compile( r'^\s*LOADPLUGINS[^\n\r]*[\n\r$]', re.MULTILINE ), r'' ),
]

replacementrules = [
	( r'.+\.(cpp|h)$', cppreplaces ),
	( r'.+\.(ini)$', inireplaces ),
	#( r'.+\.(xml)$', xmlreplaces ),
]


def ReplaceContent( file, replacelist ):    
	input = open( file, 'r' )
	filecontent = input.read()
	input.close()

	replaceCount = 0
	for replacerule in replacelist:
		replacement, rchanges = re.subn( replacerule[0], replacerule[1], filecontent )
		if rchanges > 0:
			filecontent = replacement
			replaceCount = replaceCount + rchanges

	if replaceCount > 0:
		print ( ' performed', replaceCount, 'replacements in ' + file )
		backupFile = file + '.BEFORE_V110_UPDATE.BAK'
		if os.path.isfile( backupFile ) == False:
			print ( '        backing up original file to ' + backupFile )
			shutil.copy2( file, backupFile )
		outFile = open( file, 'r+' )
		outFile.read() 
		outFile.seek( 0 )
		outFile.write( filecontent )
		outFile.truncate()
		outFile.close()
	#else:
	#	print( '         no replacement' )

	  
def ProcessFiles( root, files ):
	for name in files:
		fullName = os.path.join( root, name )
		if os.path.isfile( fullName ):
			for tuple in replacementrules:
				if re.search( tuple[0], name ):
					ReplaceContent( fullName, tuple[1] )
			
def UndoBackup( root, files ):
	for name in files:
		match = re.search( r'(.+)\.BEFORE_V110_UPDATE\.BAK$', name )
		if match:
			fullName = os.path.join( root, name )
			fullRestoreName = os.path.join( root, match.group(1) )
			print( "reverting file " + fullRestoreName )
			os.remove( fullRestoreName )
			os.rename( fullName, fullRestoreName )


if len(sys.argv) > 1 and sys.argv[1] != "":
	if len(sys.argv) > 2 and sys.argv[2] == "-undo":
		startdir = sys.argv[1]	
		print( 'startdir: ' + startdir )
		walkres = os.walk( startdir )
		for root, dirs, files in os.walk( startdir ):
			UndoBackup( root, files )
	else:
		startdir = sys.argv[1]
		print( 'startdir: ' + startdir )
		walkres = os.walk( startdir )
		for root, dirs, files in os.walk( startdir ):
			ProcessFiles( root, files )
else:
	print( 'Usage:' )
	print( 'VistaTo1.10.py ConversionRootDir [-undo]' )
	print( '  ConversionRootDir specifies toplevel dir from which on all files and subfolders will be converted, automatically backing up changed files' )
	print( '  -undo - If provided, the backups from a prior conversion will be restored. NOTE: This removes all changes from th econversion, but also all amnual changes after the backup!' )

Re: [vistavrtoolkit-general] Vista threading

[<Ger...@dl...>]

Hi,

Thank you very much for your comprehensive answers! Especially your statements concerning the synchronization between OpenSG and ViSTA are very clarifying.

I tried the Acceptor-class for accepting new connections and it works great (under both OS), thanks for the pointer.

For the dynamical change of the scene graph I decided to maintain my own (synchronized) list of change-sets between the parsing thread (XMLs are up to 0,5 MB, direct parsing with render-thread is not as smooth as I want it). Every update the (parsed and preprocessed) changes are then applied to the scene graph by the render-thread. This is (hopefully) sufficient for my purpose and allows me to use the Vista-API (and is simpler/faster for me to implement then starting to use OpenSG).

MSVC 10:
I really don't know how, but Rob...@dl... managed to build it (win7_32). =)


Best regards,

Gero


-----Ursprüngliche Nachricht-----
Von: Ingo Assenmacher [mailto:iar...@ya...] 
Gesendet: Mittwoch, 17. August 2011 21:27
An: Beer, Thomas; Leinemann, Gero; vis...@li...
Betreff: Re: [vistavrtoolkit-general] Vista threading

Some things I forgot to mention:

* it suffices to register a thread that is modifying a field container in a node, there is an opensg api for that, This means that it is not mandatory, as you might have read in my last mail, to create a thread based on opensg threads to really perform the modification. I do not have the API call in memory right now and can not access code examples, but it is quite visible in the respective opensg source. You could call that method for example in a VistaThread::Post() call or in the constructor of your thread, if you chose to subclass (if I remember correctly, it is something like "register<something>", maybe Thomas has more precise hints here).


* when playing around with the field containers, you should (to be more precise: you must) avoid using the Vista layer of the scene graph (Dominik already suggested to lock the whole vistasg during any modification). This code layer is/was not designed to be thread safe. It should be possible, however, to use most of the code in the bridges directly (there is not much state in there, so only avoid methods that change bridge state). In a nutshell: if you want to use this advanced feature: get all pointers to implementation layer objects in non-parallel code and work on the opensg structures directly.

* during syncronization, for example as done in the code that Thomas sent, you have to have access to all threads that have write access to any field container. Stop them (e.g., by using a thread barrier), sync their change lists and continue with the processing. If you do so during the vista event dispatching, you can be sure that there is no thread that is traversing the scene graph at this time.

Hope it helps,

Ingo.





----- Ursprüngliche Message -----
Von: "Beer, Thomas" <be...@vr...>
An: "Ger...@dl..." <Ger...@dl...>; "vis...@li..." <vis...@li...>
Cc: 
Gesendet: 10:35 Mittwoch, 17.August 2011
Betreff: Re: [vistavrtoolkit-general] Vista threading

Hi Gero,

There is an example on multithreading hidden in the OpenSG 1.8 sources in Doc/tutorial/progs/13multithreading_2.cpp - I attached the file.

OpenSG can store a ChangeList per thread aspect (there are exactly 2 aspects in a an OpenSG built with the default configuration) where all changes to the FieldContainers are noted. This has to be enabled explicitly, see the attached code. At specific synchronization points in the application (e.g. in a POSTLOOP Event as Ingo suggested) those lists are used to sync the thread aspects.


Regards,
Thomas

--

Thomas Beer, M.Sc.

Virtual Reality Group, RWTH Aachen University Institute for Scientific Computing Center for Computing and Communication Seffenter Weg 23, 52074 Aachen (Germany)

Phone : +49 241 80 24378
Email : be...@vr...
URL   : http://www.vr.rwth-aachen.de


> -----Original Message-----
> From: Ingo Assenmacher [mailto:iar...@ya...]
> Sent: Tuesday, August 16, 2011 10:35 PM
> To: Ger...@dl...; 
> vis...@li...
> Subject: Re: [vistavrtoolkit-general] Vista threading
>
> Hello Gero,
>
>
>
> > I'm currently using the vista threading classes (VistaMutex/Lock,
> VistaThread/Loop, VistaSemaphore, VistaThreadCondition) to implement a 
> simple application that receives a XML string, parses it and then adds 
> different nodes to the scene (at runtime).
>
> > While everything works fine under Win7_x64 with VS10, I got several
> issues/random errors/different behavior under Linux (SLED 11/gcc). To 
> be honest, I don't really know _what_ I need to synchronize (every 
> change to the scene graph, only certain calls or nothing?), and maybe 
> I'm using the Vista-API wrong (and the Win implementation is more 
> tolerant then Posix...?).
>
>
>
> OpenSG threading needs threads to be registered with the OpenSG layer, 
> otherwise, any resulting state of the scene graph is undetermined. On 
> every write to the scene graph data structures, each container checks 
> the current TID to select the correct aspect of the node-containers 
> (that is the back- buffer of the node).
> There is currently no support in the kernel to help you very much 
> here, but you can meld your own.
>
> 1) Each thread class in Vista is created by an "implementation" 
> (regard this as a factory for any platform dependent thread). By 
> default, each instance of a thread receives a NULL pointer to select 
> one of the default. You can create an OpenSG implementation and create 
> a thread using opensg threads for all threads that manipulate the 
> scene graph (yes, this can be mixed with "normal"
> threads in other places. Using the opensg api for threads lets you 
> select the proper aspect ID.
>
> 2) you have to select a place where to swap changes from the change 
> lists from any back-buffer to the front buffers of the scene graph. 
> This has to be done while the rendering is not taking place,  e.g. the 
> scene graph is not traversed. Maybe do this in a POSTLOOP event. For 
> how to do that, please refer to the OpenSG 1.8 documentation.
>
>
> I remember there was already a diploma thesis trying this out (it was not 
> hte
> major focus, but one of the working packages). Maybe Dominik can find some
> code snippets. If you need an example of how to create the OpenSG
> implementation (I doubt that... its simple), there was code in there, I am
> sure.
>
> <yourmail>
>
> ##### 1. Adding nodes to the SG
>
> // ----------------------------------------------------------
>
> This basically works (under Linux as well as Windows), but have the feeling
> that there must be a more elegant way to do this...? Or maybe the error is
> just my fault? As far as I understood OpenSG should handle synchronization, 
> or
> not?
> </yourmail>
> No, OpenSG does not handle synchronization for you. By design (version 1.8
> this is, not sure about 2.x) all you get is backbuffers (empty) on every 
> node.
> You have to chose the place of when and where to sync your state.
>
>
> <yourmail>
> ##### 2. Shutting down a VistaTCPServer
>
> I subclassed VistaTCPServer and VistaThreadLoop to handle incoming
> connections. When closing the program, the "Stop(bool)" method is called:
>
> // ----------------------------------------------------------
>
> void Server::Stop(bool wait)
> {
>     stop = true;
>     StopAccept();    // Should cause the listening thread to return from the
> socket
>
>     if (wait)
>     {
>         StopGently(true);            // Stopping thread hangs HERE
>     }
> }
>
> bool Server::LoopBody()
> {
>     if (stop) {
>         return true;
>     }
>
>     VistaTCPSocket *client = GetNextClient();    // Listening thread stays
> HERE...
>     if (client != NULL)
>     {
>         ClientConnection* cc = new ClientConnection(client, queuePtr);
>         synchronized (clientMutex) {
>             clientConnections->push_back(cc);
>         }
>     }
>
>     return stop;
> }
>
> // ----------------------------------------------------------
>
> Under SLED 11, this leads to a deadlock on shutdown: The main-thread hangs 
> in
> "StopGently(true)", while the VistaTCPServer won't return from
> "GetNextClient()" (internally: VistaTCPServerSocket::Accept). Windows works
> fine, though!??
>
> </yourmail>
>
> I would have to check the implementation of StopAccept() on unix systems, 
> but
> passing "true" to StopGently() means that any calling thread waits for a
> handshake with the loop thread. If StopAccept() does not break the wait
> condition on a unix system, then there will be no handshake, hence it will
> wait. I would not really say it is a deadlock, as I suspect that the
> GetNextClient() will return once there is a new connect and a handshake 
> could
> pass, no?. I see a check of "if(stop)...". I am not sure of where this is
> coming from, but it look suspicios, as if you are using abool to control a
> thread stop state. This is generally (not only for the Vista implementation)
> not recommended, as you never know what a compiler does with this statement.
> Some mark "stop" as volatile to avoid optimization, but generally idioms 
> like
> this lead to race conditions. Besides that... you implement "LoopBody()", so
> you could use the implementation of the ThreadLoop for state
>  control.
> In case you have more questions, feel free to ask. And if I missed something
> about the OpenSG thread model, all OpenSG gurus on the list can fire up now.
>
> Best regards,
>
> Ingo.
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> vistavrtoolkit-general mailing list
> vis...@li...
> https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
vistavrtoolkit-general mailing list
vis...@li...
https://lists.sourceforge.net/lists/listinfo/vistavrtoolkit-general