[Biojava-l] leader and trailer in Renderers

[Matthew Pocock]

Hi David,

Patch and test. You can probably knock up a dummy renderer that paints 
the sequence region grey and the leader/trailer pink (or something), 
instantiate some of these with different leader/trailer widths in a 
LayeredRenderer and check it all lines up.

The clip region should be set on a per-renderer basis to be the minimal 
rectangle containing leader/trailer. I'm a bit paranoid about clip 
bounds, having been embarased by them going wildly wrong before.

Thanks.

M

David Huen wrote:
> On Mon, 4 Mar 2002, Matthew Pocock wrote:
> 
> 
>>The leading and trailing space is requested per renderer. This is 
>>because some glyphs (e.g. numbers) are scale-invarient and will be 
>>clipped off if the rendering is clipped exactly. I think the container 
>>of the sequence renderers loops over these and finds the maximum one. 
>>Then, it individualy translates each sequence renderer so that their 
>>sequence-based co-ordinates line up, but they are guaranteed a minimum 
>>of leader and trailer padding. Does that help?
>>
>>
> In which case I think LayeredRenderer is buggy.  It has its own
> getMinimumLeader/Trailer methods that compute to the value required
> to fulfil the requirements of all renderers but in the draw loop, it
> actually calls that of the renderer being invoked at that time:-
> 
>             SequenceRenderer sRend = (SequenceRenderer) i.next();
>             int dir = src.getDirection();
>             double depth = sRend.getDepth(src);
> 
>             // Sequence range should be inclusive of the min/max
>             // coordinates for sequenceToGraphics() so we use
>             // src.getRange().getMax() + 1
>             double minP = src.sequenceToGraphics(src.getRange().getMin())
> -
>                 sRend.getMinimumLeader(src);
>             double maxP = src.sequenceToGraphics(src.getRange().getMax() +
> 1) +
>                 sRend.getMinimumTrailer(src);
> 
> It is wrong, isn't it?  There also appears to be a bug in the getDepth
> method which fails to account for overdrawing. The latter is almost
> certainly caused by me from a long time ago.
> 
> If we are agreed the above is wrong, I'll patch it and upload.
> 
> Sorry for the bother - I'm not think very clearly just now and I don't
> want to break the thing just before a bootcamp.
> 
> Regards,
> David Huen
> 
> 
> 
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> 
>