timeline upgrade

The Chronicle control I developped for ViPER-GT 4 is proving too brittle. It is based around the idea that there should be one PNode for each segment of a descriptor; these are generated by a factory method. This saves a lot on code reuse, and each segment only has to know how long it should be and the value it represents, so it is pretty easy to develop new shapes. However, I haven't really added any new shapes, and it is a very constraining design. Also, it can lead to tens of thousands of subpixel polygons being rendered on the screen, which tends to slow the system down.

The new system will require the delegates to handle the whole line, not just individual segments. Code resuse can be effected using object oriented methods, or additional delegates, so the new classes shouldn't be much uglier than the ones they are replacing. While I'm doing this, I also should work in a couple of new features that have been wanted for a while.

The first is a generic 'overlay' layer, that the user can have access to. Basically, this will be used for things like dragging new lines, drawing relation links, and any sort of overlays that may come up that will might not be strictly within the rectangular bounds of a single timeline. This might include things like highlights for determining which object to select on the timeline. For example, the current 'line dragger' control can now draw here and change the api data on dragFinished, instead of the current hack that edits the line during dragging and commits the transaction on dragFinished. Another example is ctrl-clicking to select the line or the

The other feature is good implementation of dynamic line reshaping, including two major features: direction (vertical v. horizontal) and line width (basically, 1-pixel for lines that aren't of interest, to 'enough' for lines of interest, to 'user specified width' for annotation and editing). This means that we can do things like 'minimize lines for descriptors that aren't valid'. This might be a little hectic, so an arbitrary 'setWidth' could allow for smooth scaling, if required. Another possiblity would be to scale to the 1-pixel height in place, then collapse smoothly, which would probably use a lot less CPU. Maybe we could fade the old lines?

- posted by David @ 3:40 PM

generic notes about ViPER development

I keep ViPER's source code in a local (cfar) repository, to avoid the annoyance of using Sourceforge's buggy system (which I do use for the web site). The CVS repository is located on bo, so you can access it through any of the cluster machines. Since bo's shell access might be limited, I actually have CVS set up to ssh into lampblade2. To check out the project, you can configure CVS to use 'ssh' to connect to 'bo.cfar.umd.edu', with the root as '/fs/lamp/Projects/cvs'. This should give you a listing of a variety of projects. The one of interest here is 'viper'. If you don't need write access, you can just download the viper-full package from sourceforge.

Once the project has been checked out, Eclipse will know how to build it. If you downloaded the full package, you will have to use the 'import > project' command in Eclipse. If you aren't using eclipse, you'll have to know how the source directories are arranged. There is an ant build.xml file you can use; I'm pretty sure the makefiles don't work anymore. Basically, they build all the java source files, located in the '*/src' directories, to the corresponding '*/classes' directories, then make a bunch of java application archive files. Most IDEs support multiple source directories. In Eclipse, I have them set up to all output to the single directory, '/classes', contrary to how the ant build process in configured.

There are six different source directories; each one is built into its own jar file by the build.xml file. 'api' contains the ability to load and save viper metadata, as well as a variety of shared utility classes and methods. 'jmpeg' is the pure java mpeg-1 decoder. 'chronicle' provides a timeline Java UI widget. 'apploader' provides tools for reading in Javabeans application descriptions from OWL files. 'pe' provides the performance evaluation tool, and is also used to convert between the older text format and the newer XML format. Finally, 'gt' provides the code for the metadata editing tool, or 'Ground Truth editor'. You can get a unified view of all the classes through the generated API documentation, although that is not up to date.

- posted by David @ 3:35 PM