[Biojava-l] SequencePanel arbitrary setGraphicsOrigin

[Dr S.M. Huen]

On 24 May 2001, Keith James wrote:

> 
> Hi,
> 
> I'm working on a couple of things related to the sequence gui code,
> namely:
> 
> A new FeatureRenderer to do 'mixed types of beads on a string'
> rendering for protein domains etc (rather than overlaying several
> SequenceRenderers)
> 
Nice.

> Dumping png images of rendered features.
> 
> When using a Graphics2D obtained from a SequencePanel to output a png
> image I'm getting all the features mysteriously offset a bunch of
> pixels to the right (although things seem fine on the gui panel
> itself).
> 
> I've tracked this down to
> 
> setGraphicsOrigin(50.0-sequenceToGraphics(range.getMin()));
> 
> being called in paintComponent()

This was done to fix a problem in the representation of pixel coordinates
in the Graphics2D internals.  When SequenceRenderContext was used in the
past, the values of pixel coordinates generated were so large that
floating point representation errors  were causing drawing to be done at
incorrect locations (differencing of very large numbers).

SetGraphicsOrigin() just applies a large negative displacement to the
sequenceToGraphics() coordinates so the range of pixel values falls in the
low positive range (the actual values being arbitrary owing to a further
transform applied by the drawing code).  It got rid of many drawing
problems.  The value passed to SetGraphicsOrigin is unimportant as as long
as it puts it in the positive low-value range.

> 
> This results in features vanishing off the right hand edge of the
> image and corresponding blank space to the left. If I comment this
> out, all returns to normal.
> 

If you could send me you renderer code I could have a look at why it might
be doing this. Do you have a framing/clipping transform to put it in the panel
like the MultilineRenderer and LayeredRenderer classes?  It is those
original transforms that really do the work of placing the drawing - the
setGraphicsOrigin() is just a workround that makes them work properly with
potentially huge pixel coordinates.  I think you must be drawing directly
rather than in one of the wrapper classes that create a transform for the
other panels that has resulted in this going funny and why removing the
offset fixes it.

I'll be up at the Sanger to see Matt Pocock and Thomas Down tomorrow
afternoon so I could have a look then.  Alternatively, you could email me
your renderer source and some description of how it works and I'll try to
fix this problem.

Regards,
David