Advanced User Interface Software 2000 Benchmark

SMIL User Agent:

Benchmark 2 - Java 3/14/2001

Jack Zaientz
412-241-7342
810 Rebecca Ave, Apt. 5
Pittsburgh, PA 15221
jackrabbit@puddledock.com

This Document: http://www.puddledock.com/cmu/auis/report2.html
Proposal Slides: http://www.puddledock.com/cmu/auis/proposal1.html
Presentation Slides: http://www.puddledock.com/cmu/auis/presentation2.html

Introduction

This benchmark is a simple multimedia player, or user agent, that loads and plays SMIL files and allows users to have simple control of playback. SMIL is an XML based language created by the W3C organization to allow TV-like multimedia presentations to be delivered via the WWW. SMIL’s TV-like capacities include the ability to present captions or audio over-dubs when requested by users. SMIL supports multiple concurrent video and audio files.

While there are few SMIL user agents on the market at the present time, this player resembles other multimedia players such as the RealMedia RealPlayer and Windows Multimedia Player. It will be implemented as a direct manipulation interface. As a benchmark, the SMIL User Agent will test a toolkit’s ability to parse XML documents; to display and control various media types, including images (.GIF, .JPG), text, audio (.AU, .WAV, .MP3), and video (.MPEG,.AVI); create, control and interact with objects at runtime..

Description of Benchmark Task

The SMIL User Agent may be implemented as either an applet or a stand-alone application. It should, at minimum, present a mechanism for selecting captioning and overdub preferences, a mechanism for selecting and loading a file, a multimedia content display screen, a button to play the multimedia file and a button to stop the multimedia file.

The SMIL file defines a set of screen regions and content to place in those regions and specified times to place and remove that content.  This benchmark will create and co-ordiante each screen regions seperately.  It will not use a media player (Windows Media Player, Real Player) widget to host the SMIL display, only to display relevant media types. The SMIL player will support multiple concurrent instances of each media type. 

Description of Visual Basic Implementation

Platform:

I used Java 1.3, with Swing 2.0 on Microsoft Windows NT 4.0, with the Java Media Framework, the MediaPlayer JavaBean and Sun's JAXP XML Parser (using its SAX implementation).  I developed in Sun's Forte environment and Microsoft's IDE. My development/test machine was a standard IBM PC.

Specification:

The original benchmark description was adequately specificied to be buildable.  The only change made was to simplify the benchmark by decressing the amount of SMIL functionality implemented. Specifically, TEXT, and ANIMATION types were not implmenented. SWITCHing was not implemented either, so the options screen has no impact on application behavior.

The only addition to the specification was the use of the JAVA JFileChooser class to add the standard a "File Open" dialog box.  This is a standard practice and required only a few lines of code.

The only two features that were not implemented up to my satisfaction were timing issues and absolute placement of graphic files.  The standard SWING timer is not very eliable, much less so than the VB timer.  Using it caused inconsistent displays.  The reason for the difficulty with placement of graphic files is not clear.  I would assume it is a bug in my code, not a problem with the toolkit, but if it is it's an elusive bug.

Experience with Java/Swing:

A bit better than novice. I am familiar with object-orient programming but used Java for the first time last semseter in Scott Hudson's class.  I had never used SWING (or AWT), JMF or the JAXP XML parser prior to this benchmark.  On the otherhand, this is the second benchmark so I had already developed a stable class architecture that was relatively easy to port in to Java and have developed an understanding of the XML SAX interface, SMIL, and presentation issues.

Documentation:

My primary references were the Sun's online documentation and tutorials. In particular the following areas:

SAX XML Parser

http://java.sun.com/xml/

http://java.sun.com/xml/jaxp-docs-1.0.1/docs/api/
Forte

http://www.sun.com/forte/ffj

http://www.sun.com/forte/ffj/resources/documentation.html

SWING

http://java.sun.com/docs/books/tutorial/uiswing/

http://java.sun.com/docs/books/tutorial/uiswing/misc/plaf.html

http://java.sun.com/j2se/1.3/docs/guide/swing/index.html

FileChooser

http://java.sun.com/j2se/1.3/docs/api/javax/swing/filechooser/package-summary.html

http://java.sun.com/docs/books/tutorial/uiswing/components/filechooser.html

JavaMedia Framework

http://developer.java.sun.com/developer/technicalArticles//Media/Mediaplayer/index.html

http://java.sun.com/products/java-media/

I also made good use of Deja News. Deja, which is in the process of being bought by Google, is a searchable web-driven database of Usenet posts dating back to 1995.  Generally, if I have a question, someone else did too, and I can go find the answer.

Statistics:

Quality of Tool:

Java is like a beautiful weed. You can architect elegent solutions with it, but it has so many classes and libraries available of varying quality that it is difficult for a newcomer to make sense of it all.  It offers more control than a language like VB, but it's at a cost. It's harder to configure, and harder to structure effectively. It also doesn't seem to support elegant interfaces.  That being said, I'm growing fond of it.

Learnability is tough to judge. I was able to come up with a reasonable solution fairly quickly, but I don't know how well it would compare with an expert solution.  Particularly in SWING, itt's hard to wrap your head around how the language wants to be programmed. There are a large number of conceptual models you can choose from and it's not always clear what classes or procedures support them well.

In general, I the run time performance of  Java/SWING is generally sufficient,  but definately slower than VB.

Good Aspects of Tool: Much like VB, the easiest aspect of the benchmark to program was the XML input and the video stream output.  What could be done, could be done very quickly. 

Not so Good Aspects: Doing interactive layout in Forte was much more difficult than it needed to be.  Also, as noted above, determining the expected way to implement any thing in Java is difficult.

Debugging: Since I couldn't utilize an IDE for developing this (Forte was too slow, and Microsoft had too old a compiler) all debugging was harder than it needed to be.

Benchmark:

As noted above the benchmark is adequately specified to implement, but the specification calls for a level of interal complexity and refinement that is a bit large for the goal of a benchmark task. To improve this as a benchmark, this complexity has to be reduced a bit and some internal functionality (SMIL compliance) has to be sacraficed.  That being said, it is a good test of XML parsing and media processing as it tests a wide number of formats and conditions.

Screen Shots

Main Screen

Common Dialog Control

Playing simultaneous video streams (both MPEG)

Playing image files (both gif)