Performance issue on Mac when go to previous/next segment
Jeongkyu Kim
I recently changed my working environment from Windows to MacOS X and
experienced performance issue when tried to move between segments
using keyboard. Depending on document size, it even took 2-3 seconds
just to go to previous/next segment.
While I was tracing down the issue, I found it was caused by bad
performance of JTextPane (used in TranslationView) on Mac version of
Java. If translated text is big enough, it takes long time on Mac to
reset the text on TranslationView.
Thus the issue might be solved by
- reducing the size of text displayed on TranslationView or
- avoiding the reset if TranslationView is turned off.
It seems to be OK for me to display the translated text from current
segment only. And the following fix works for me.
In TranslationView.java
public void setTranslation( final SourceTextEntry ste )
{
final int iFirst = ste.getFirstInFile();
final int iLast = ste.getLastInFile();
final TextBuilder txtBuf = new TextBuilder();
final Manager mngr = Manager.getInstance();
// // Loop segments
// for( int iEntry=iFirst;iEntry<=iLast; iEntry++ )
// {
// final SourceTextEntry steCurrent = mngr.getSTE( iEntry );
// String strText = steCurrent.getTranslation();
//
// // no translation available - use source text
// if( strText.length() == 0 ) strText = steCurrent.getSrcText();
//
// txtBuf.append( iEntry + 1 );
// txtBuf.append( ": " );
// txtBuf.append( strText );
// txtBuf.append( "\n" );
// }
String strText = ste.getTranslation();
if( strText.length() == 0 ) strText = ste.getSrcText();
txtBuf.append( ste.entryNum() + 1 );
txtBuf.append( ": " );
txtBuf.append( strText );
txtBuf.append( "\n" );
setText( "" );
setText( txtBuf.toString() );
}
However, if the purpose of the TranslationView is to display whole
text then the second solution might be necessary for Mac users.
Jeongkyu
--
Jeongkyu Kim
OpenOffice.org Korean community lead
Community website http://openoffice.or.kr
Personal blog http://openoffice.or.kr/gomme
Raymond Martin
Hi Jeongkyu,
On March 18, 2011 03:57:14 AM Jeongkyu Kim wrote:
>
> I recently changed my working environment from Windows to MacOS X and
> experienced performance issue when tried to move between segments
> using keyboard. Depending on document size, it even took 2-3 seconds
> just to go to previous/next segment.
Sure, depending on document size, how much matching is being done, system speed/RAM, etc.
> While I was tracing down the issue, I found it was caused by bad
> performance of JTextPane (used in TranslationView) on Mac version of
> Java. If translated text is big enough, it takes long time on Mac to
> reset the text on TranslationView.
Mac seems to have a few efficiency issues in regard to certain parts of Java display of text. These may be solved in future once Oracle becomes the one to distribute Java for Mac.
> Thus the issue might be solved by
> - reducing the size of text displayed on TranslationView or
> - avoiding the reset if TranslationView is turned off.
Right on both accounts. Avoiding reset when the view is off (or possibly minimized) is something that was missed and I should have done it. Reducing the size of text displayed brings up questions of general usage of this view which need to be improved going forward.
> It seems to be OK for me to display the translated text from current
> segment only. And the following fix works for me.
>
> In TranslationView.java
> ...
>
> String strText = ste.getTranslation();
> if( strText.length() == 0 ) strText = ste.getSrcText();
>
> txtBuf.append( ste.entryNum() + 1 );
> txtBuf.append( ": " );
> txtBuf.append( strText );
> txtBuf.append( "\n" );
>
> setText( "" );
> setText( txtBuf.toString() );
> }
Of course, that works if you only want to see one translated segment and leaving out the redisplay of the rest certain cuts down on the time element involved.
> However, if the purpose of the TranslationView is to display whole
> text then the second solution might be necessary for Mac users.
>
I am wondering if any significant number of regular users of the program actually get benefit from this view. What is there now is just a first effort towards what I had in mind, for users to be able to get some kind of overview of the resultant translations of a whole document without having to generate the translation documents repeatedly, go to an external program and open/reopen it
I have been working on some other improvements in the user interface (Metrics) that change the way data is displayed. If implemented then individual elements (e.g., rows) can be altered without redisplaying everything each time segments are moved between. Once I have more of that done in the other areas of the UI I think I can carry it over to the Translation/Original Views.
We will have to see though because I am not completely certain whether to keep or drop these views. If good quality improvements can be made to these sooner than later then it is more likely they will stay.
Anyway, I guess you are okay for now since you changed that. If not let me know, but I am trying not to distrbute a new version of the program until I have more of the changes in place that have been going on. If you have a severe bug, broken document filter, etc. then I can make a fix and send it out to you, or whoever has an issue.
Thanks for bringing this issue to my attention and your patience.
Raymond
P.S. If you can, please file this as a bug on the SourceForge project (you need to be an SF member now to do this).
NOTE: SPAM had been posted on the SourceForge tracker previously so no more anonymous reports are allowed.
Jeongkyu Kim
> Thanks for bringing this issue to my attention and your patience.
>
> Raymond
Thanks for your kind reply. :-)
>
> P.S. If you can, please file this as a bug on the SourceForge project (you
> need to be an SF member now to do this).
>
I just filed and issue.
https://sourceforge.net/tracker/?func=detail&aid=3241239&group_id=141182&atid=748748
Best regards,
laseray
On Mar 24, 1:01 pm, Jeongkyu Kim <jeongkyu....@gmail.com> wrote:
>
> > P.S. If you can, please file this as a bug on the SourceForge project (you
> > need to be an SF member now to do this).
>
> I just filed and issue.
>
Okay, thanks.
Raymond