Eric Morgan
Renegade Geophysics, LLC
There are some minor graphical glitches involving XOR
drawing, window sizing, font scaling and display refreshing. Settings issues have been resolved, and
Seismic Studio may now be installed in a more global prefix such as /usr/local in order to allow access on multiple
workstations. Settings will be stored in
each users $HOME directory.
Installation procedure has been stripped down a little, and requires
setup of 2-3 environment variables in order to get the installation working
properly. This setup is quick and easy
to support, rather than trying to write a large setup script to accommodate all
platforms and users. Unfortunately, due
to an issue with our licensing vendors, 64bit versions may come later. Weve compiled and things seem very smooth on
RedHat Linux 64bit, but the 3rd party are incompatible and we are working on getting
libraries that will. We have plans to
redo our graphics system in order to provide significant performance
enhancements when working with our windows, that will also address many of the
graphical glitches involving XOR drawing and refreshing displays. However, we believe this is more of a feature
enhancement and will be patched after the release of Seismic Studio on Linux.
32bit:
64bit: TBA
http://bugzilla.ximian.com/show_bug.cgi?id=75933
http://bugzilla.ximian.com/show_bug.cgi?id=77122
http://bugzilla.ximian.com/show_bug.cgi?id=77936
http://bugzilla.ximian.com/show_bug.cgi?id=80976
http://bugzilla.ximian.com/show_bug.cgi?id=77940
http://bugzilla.ximian.com/show_bug.cgi?id=77972
http://bugzilla.ximian.com/show_bug.cgi?id=78198
http://bugzilla.ximian.com/show_bug.cgi?id=78355
http://bugzilla.ximian.com/show_bug.cgi?id=78405
http://bugzilla.ximian.com/show_bug.cgi?id=80877
http://bugzilla.ximian.com/show_bug.cgi?id=81153
Rubberbanding
Rubberbanding is a term used for the DrawReversible* functions in the .NET framework. They draw a line, rectangle, or filled
rectangle given a point A and a point B, like stretching out a rubber band. This drawing is done in an XOR fashion, where
the line is superimposed on the paint control.
This drawing avoids function calls to the Paint() method, so the paint control does not have to repaint
itself in entirely.
The issue in the Mono Framework,
is that many controls have extra (an unnecessary) Invalidate() and Refresh() methods called,
which ultimately call the OnPaint()
function for the control in
question. What this causes is the
drawing of the rubber band lines through XOR drawing, but then the paint
control immediately being repainted due to the extra OnPaint() method. Since
these rubberbanding graphics are not stored, just
painted directly, they are removed during the repaint of the control. This mainly happens when the mouse is within
the control doing the drawing, as clicks and other events are forcing the
control to repaint itself. It can be noticed that rubberband
lines not in the same control are painted and retained just fine, as when
moving the mouse over traces and the vectors from source to channel on the basemap are displayed.
Rubberbanding
is used in Seismic Studio in the following ways: Zoom Boxes, Vector Drawing on Basemaps, Crosshair movement in delay time picker, Branch
assignment triple line definition, Control Point Picking, LMO trend
setting.
Client Size Areas
Many modal windows or user
controls in certain situations are showing their client area to be smaller than
the actual size needed for the control.
The effect is a window will open and you can not see the entire contents
of the window, because it is being cut off by the smaller client area. In some cases, this is minor and resizing the
window will force the client area to synch up and everything will display
properly. In others, it remains an issue
and prevents you from progressing further.
The cause of this is believed to be an issue with anchoring controls in
a window. When the .Anchor value is set to top, left, right,
the controls tend to extend off to the right of the window area, while when the
.Anchor value is set to with an additional bottom property, the area extends off the bottom of the
window area.
We are testing the windows and trying to figure out
which ones are showing this behavior.
The fix seems to be putting the controls into a Panel, docking the Panel, then
putting the appropriate controls into the Panel with its
own dock values. This has fixed many
issues, especially with ListView
objects.
Font Scaling
Further testing has shown that
window sizes can be drastically disproportioned when the .AutoScale
property of a modal dialog window is set to true. The Microsoft Sans Serif font is handled
differently on Linux, causing windows to be sized differently than on
windows. Turning this property to false
fixes the majority of these issues.
Window State Saving
Currently, Seismic Studio on
Linux will not load what windows were open prior to closing the application
down. This is because of a glitch (in
the windows version too) that causes window sizes to be automatically
increased. Thus, after every opening of
the application the windows will grow a little bit in size. The main application window MainForm also grows in size.
This is not an issue in the windows version, because the amount it
increases by is small and can usually be manually resized on the fly. However, in the Linux version, it is
compounded by the previous font scaling issue, inflating the window sizes by
50% or more. This means that on the
first time reopening the application, you can end up instantly in a state where
the bottom of the window (where you need to click and drag to resize) is far
off screen.
We currently do not have a
solution, but resolution of it even on the windows version should allow us to
enable this feature on Linux as well.
Refresh Issues and Minor Glitches
In a few windows, changing state
information, or loading certain things (especially in relation to basemaps and crossplots) will not
redraw properly. All instances of this
found so far have been able to be corrected by clicking a load button, right
clicking on the control, resizing the window, or other navigation method. It should be a simple fix, but the simple fix
may result in performance decreases due to it repainting itself an extra
time. We are compiling a list of windows
that contain these issues so that we can go in and fix them all at once.
Platform Migration
Since most processing shops use
some variation of RedHat (CentOS,
Fedora), we have migrated our development environment from SuSE
10.1 to RedHat 4.3.
After some technical issues and a bunch of hardware failures, we have
development environments for both x86 and x86_64 platforms. Development will be continued and the main
supported Linux distributions will be the previously mentioned derivations of RedHat. We will
provide RPMs or a TAR archive for installation of
Seismic Studio when it is released.
Licensing
The only complication with
getting a 64bit version of Seismic Studio running on Linux is our
licensing. We are using Aladdins HASP
for single-key standalone licensing and SafeNets
Sentinel Hardware Keys for network licensing.
Both of these options were derived for our windows version, and
migrating them to Linux is not as simple as migrating existing .NET code, since
these 3rd party libraries are most likely not .NET code to begin
with.
Licensing Hasp
HASP keys can be set up for
network licensing as well as standalone workstation licensing, through the use
of HASP License Manager (HASP LM). The problem, is that we still need a HASP library to communicate
with the server. The libraries Aladdin
provides for Linux are all C based static libraries. This means that these libraries must be
linked against at compile time, which will literally copy the library contents
into the executable. Since Seismic
Studio is not C code and we are not compiling it on Linux, static linking these
libraries into Seismic Studio is not an option.
Additionally, Aladdin has stated that we cannot link this static library
into a shared object, so we cannot just write a wrapper around it and P/Invoke
into that shared object. We have tried
extracting the object files from the *.a static
library and compiling them into a shared object ourselves, but the object files
were not compiled using Position Independent Code (-fPIC option for gcc compilers)., so this
fails. The result is that until we either 1.) compile Seismic
Studio in the Linux environment and statically link the library into our application
or 2.) wait for a bug fix from Aladdin that allows the static library to be
linked into a shared object, we cannot use HASP or HASP LM for our licensing
(option 2 is even more out of reach, because they havent made an update to
that particular library in almost 2 years).
Licensing Sentinel
Our 32bit distribution of
Seismic Studio will be using SafeNets Sentinel to
license its users. This currently works
very well on RedHat 4.3. However, this library is not backwards
compatible and can not be run on the 64bit platform. P/Invoking into the provided shared object libSentinelKeys32.so shows that the library cannot be found. Mono uses dlopen(3) to open shared libraries for P/Invoking, and a quick
check with some C code making use of the system call gives the same
results. We have, however, tried
compiling the provided C wrapper around the Java version of the shared
object. It gave us errors as well,
saying that the input is incompatible with the output on x86_64 bit
platforms. We have been in constant
contact the past week with SafeNets technical
support in hopes of getting them to make a shared object that will be
compatible with the 64bit platform. They
have stated that their project management team has been notified and will
decide on the schedule for this feature request this week. Seismic Studio 64bit can be released after
this issue is resolved.
Graphics System
Currently, our custom graphics
we use for our displays are admittedly outdated. The main control we use, BasePaintControlGraphics, draws objects on a canvas and then uses XOR objects
to draw what it needs in real-time. Some
of these XOR objects work, but the ones that use the DrawReversible* functions as mentioned previously do not, unless they
are being painted to a control without focus.
We intend to revamp this graphic system to incorporate a few things that
will improve the Linux version.
First, we want to implement
double buffering. Double buffering is
the process of writing bulk graphical changes to an object in memory before
displaying it to the screen. When trying
to draw too many things at once on the canvas, the canvas refreshes each time
and it causes a flickering effect.
This flicker effect is due to drawing to a display being slower than writing
to physical RAM. This will improve load
times of things like base maps, trace displays and cmp
pick plots.
Second, we want to move away from the XOR-based
drawing. XOR-based drawing was used
years ago before the advent of double buffering and faster graphics cards. We can safely store the XOR object as a PaintableObject and redraw the display through the use of double
buffering. The performance decrease is
negligible because of double buffering and will solve all of the issues using
the DrawReversible* functions (we wont be using those functions
anymore).
Third and finally, we intend to
make use of a dirty system. Mono
currently has a lot of excess calls to .Refresh(), which causes these graphics displays to be
unnecessarily redrawn. For example, in
the picker window, when you click anywhere in the window at all, it redraws the
trace display twice and the base map display twice in succession. By overriding the .Refresh()
function with our own, we can catch these refreshes and make sure that the
control is actually dirty. If it is
dirty, we proceed with the refresh, otherwise abort it. This will help the clunky feel Mono can
have on slower systems or on systems with non-standard OpenGL APIs (like the
MESA project, which is usually default on most Linux systems). This feature will be slightly overshadowed by
double buffering since the refresh times of the controls will be so much
shorter, but will be a quick performance enhancement that wont take much more
effort during a revamp anyway.
Picker Window
A rather ambitious idea, the
mention of a new picker window gives us mixed feelings as well as our
users. The picker window is one of the
most used windows in our application. A
small side effect of this being that it turned into a house of cards due to all
the development done on it. The window
itself is almost 4 years old and has evolved into something very difficult to
maintain. Any bug fix or alteration to
the picker window has to undergo rigorous testing since things are easy to
break. Our plan is to rewrite and
redesign the conventional picker window in order to make it more intuitive and
easier to maintain. Dont panic! The old picker window will still always be
available for those that prefer it. However,
we hope that the redesigned picker window will slowly lure our users in.