[Biojava-l] Overlaid drawing class

[Dr S.M. Huen]

On Mon, 21 May 2001, Matthew Pocock wrote:

> Hi
> 
> I sudgest that you create a new class called OverlayRenderer that 
> maintains a list of renderers much like MultiLineRenderer does (rip off 
> the listener manager code - it's debugged now!). It returns max rather 
> than sum over child depths for getDepth, and doesn't translate the 
> graphics context when rendering. This should be easy to write.
> 
> While you're at it, you may wish to write an OverlayFeatureRenderer that 
> allows multiple feature renderers to render to the same area of screen, 
> and then write a FeatureSequenceRenderer that is a FeatureRenderer that 
> invokes a SequenceRenderer for just the region contained by that feature.
> 
> That way, you could have a renderer for an exon that is an overlay of a 
> box renderer and your stop-codon sequence renderer.
> 
Too late, I'm afraid... ;-).  I went ahead and bodged a fix along very
similar lines.  Basically a few lines in LayeredRenderer detect a renderer
to be an instance of OverlayMarker, a content-free interface.  Then a
OverlayRendererWrapper class is defined that implements OverlayMarker and
wraps other renderers.

Using this, I've implemented a SixFrameRenderer class that is used by
other SixFrame renderers (SixFrameZiggyRenderer and StopRenderer) to draw
to screen.  The internal API between them is non-ideal and subject to
drastic change soon (bascially to have SixFrameRenderer return an inner
class object that the other renderers use to draw and maintains state info
for the artifact being drawn).

The SixFrameZiggyRenderer changed in design somewhat from what I had
intended initally.  I thought I could get the DAS servers to return me
CDS info (ie the exons truncated at start and end by the initial and final
codons). This can be rendered in the correct frames without triggering any
sequence download. But I couldn't get that info so I have extended the
renderer to take the transcript and figure out the longest ORF and
render assuming that to be the correct frame.  It's more expensive on
cycles and bandwidth but not too bad.

As there are more files that this NG may appreciate having, I have
uploaded the files and will leave them at the following site for a week or
so until they are put into CVS (Once it is verified to be OK, could
someone arrange that please?).
http://www.huen.org.uk/changes.tgz
http://www.huen.org.uk/SequenceViewer.java

The former should be untarred in the biojava-live folder and the latter
has the renderers configured into it for a demo.  Please check that it
works correctly.  It seemed to with the CVS live version as of this
morning.  Incidentally, the stop codon renderer will not render when
completely zoomed out as it figures you couldn't possibly want to find
every stop frame over megabase regions.  Just zoom in a bit and it will
kick in.  There is also a buglet when zoomed out where the ruler is drawn
in the incorrect location but corrects itself once the six stop frames are
rendered.  This is caused by my fault in returning getDepth() which I will
fix next iteration.

I was thinking that perhaps we should have a separation between renderers
and layout tasks in the classes so it is possible to define an area of
screen as an layout object and have that object return objects that the
renderers use to draw to that area.  If it is thought to be worthwhile, I
might have a go at it if I feel sufficiently masochistic.

Regards,
David