[ ... ]
Long story...
This came about because SequencePanel had two problems:
1. It will by default render a huge sequence in a single huge coordinate space which leads to floating point errors in marking tics/points at the far end of the sequence.
To solve this a hack was put in to translate the drawing coordinates to ~0 before drawing. However that broke rendering to any Graphics2D derived from a BufferedImage where it produced an un-renderable region between 0 and the offset (which was 50 pixels wide, if I remember)
2. It was far too slow with available sequence/feature renderers.
So I wrote TranslatedSequencePanel which solves the first problem without using the offset hack. Instead of placing a huge virtual rendering area in a ScrollPane, it clips a window of sequence to render and runs the window along the sequence. Therefore you are always drawing from 0, even at base 100,000,001 of the sequence.
As a nice side-effect, it also turned out to be 5-10x faster at rendering with the current sequence/feature renderers.
But people were still using the SequencePanel in their client code, so I didn't want to remove it.
Keith
Matthew have done some work on the rendering part, there is now a class called org.biojava.bio.gui.sequence.GUITools that contains some helper methods, so that SequenceRenderers can figure out what part is visible, so they can limit rendering to the visible parts. From a quick test, the speed with SequencePanel seems comparable to the speed you get with TranslatedSequencePanel.
I dont know if he has fixed issue number 1 aswell, but i will try to take a look
at that later on today, and see if i can see the rendering errors with the CVS
version of SequencePanel.
Kalle
_______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
