Jump to content
  • Slow JRViewer


    tcloonan
    Assigned User lucianc
    CategoryBug report
    PriorityLow
    ReproducibilityAlways
    ResolutionFixed
    SeverityTrivial
    StatusClosed

    Original issue moved from:

    https://sourceforge.net/tracker/index.php?func=detail&aid=1441885&group_id=36382&atid=416703\

     

    Consult the original issue for any attachments.

     

    [ 1441885 ] Slow JRViewer

     

    Submitted By: jorge - sirion_oef

    Date Submitted: 2006-03-02 09:21

    Last Updated By: pmichalek - Comment added

    Date Last Updated: 2006-06-18 11:47

    Number of Comments: 12

    Number of Attachments: 0

     

    Assigned To: Nobody/Anonymous

    Priority: 5

     

    Summary:

    Slow JRViewer

     

    i recently upgrade to 1.2.0 and notice that JRViewer is very slow when i try to use the weel button (the middle button) of the muose for move up and own the page, but when i use the horizontal scroll bar it's not

     

    Comments

     

    Date: 2006-06-18 11:47

    Sender: pmichalek

    Logged In: YES

    user_id=830953

     

    ...

    4. Also there should be turned off antialiasing - speeds up X11, but antialiasing in freenx is fast. (antialiasing should be configurable parameter)

     

    5. some hacks, that speeds up viewer containts patch 1367087

     

    http://sourceforge.net/tracker/index.php?func=detail&aid=1367087&group_id=36382&atid=416705

    Date: 2006-06-18 07:06

    Sender: pmichalek

    Logged In: YES

    user_id=830953

     

    JRViewer is slow because repaints whole page (including invisible parts)

     

    In class JRGraphics2DExporter:

     

    1. do not override clipbounds.grx.setClip(new Rectangle2D.Float(0, 0,jasperPrint.getPageWidth(), jasperPrint.getPageHeight()));

     

    2. In method exportElements() test if element is in clib bounds. protected void exportElements(Collection elements) throws JRException

    { ... if (!grx.getClipBounds().intersects(element.getX(),

    element.getY(), element.getWidth(), element.getHeight()))

    continue;

     

    Regards

    Petr Michalek

     

    Date: 2006-06-02 11:05

    Sender: kyleki

    Logged In: YES

    user_id=1044043

     

    Right, I realized that once I started looking into the code to see if I could help out in any way. The number of pages in our case is directly related to how large the dataset is, so I'm guessing it's a combination of the dataset and our layout. We're utilizing the title band to display 3 timeseries charts (1 large line graph and 2 small area charts) of all the data in the dataset. We're then using the column header, detail, and column footer bands to display the raw data in table form.

     

    I've noticed that it's basically just the first page with the charts that's so sluggish it's unusable (even when clicking and dragging the scroll bar - not using the scroll wheel on the mouse). The other pages with the table information perform quite a bit faster, but are still slow with the mouse scroll wheel. At least these other pages can be zoomed and moved around MUCH easier.

     

    So, perhaps the issue we're seeing with the charts on the title page is a separate issue. Is this something we should log independent of this particular bug? Can you think of any short term pointers to help us out with our layout strategy in terms of performance?

    Date: 2006-06-02 07:58

    Sender: teodordProject Admin

    Logged In: YES

    user_id=332465

     

    Hi,

     

    The number of pages should not affect the performance of the viewer unless you really use a small amount of memory for your application and time is spent garbage collecting things to free up memory. The viewer has the same page rendering speed no matter how many pages are in the document.

     

    Thank you,

    Teodor

     

    Date: 2006-05-31 14:47

    Sender: kyleki

    Logged In: YES

    user_id=1044043

     

    We're using JasperReports 1.2.2 and this is practically unusable for us. When generating reports that utilize graphs with lots of data (120 pages worth), JRViewer is so slow it's painful. When our reports have less data (3-5 pages worth), the viewer is usable, but still a bit sluggish.

     

    We've extended JRViewer, but only to override some of the toolbar buttons and actions. What type of things have you done, C-Box that makes your implementation more responsive?

     

    Date: 2006-04-18 01:26

    Sender: teodordProject Admin

    Logged In: YES

    user_id=332465

     

    C-Box

     

    You mentioned you have an enhanced viewer? Would it be possible to share some ideas/code with us?

     

    Thanks,

    Teodor

     

    Date: 2006-03-07 08:39

    Sender: sirion_oef

    Logged In: YES

    user_id=1219142

     

    the bad thing is that i don't have time for make these changes :(

     

    Date: 2006-03-07 03:28

    Sender: c-box

    Logged In: YES

    user_id=1021972

     

    Just my two cent -

     

    we do use our own JRViewer instead of the Jasper integrated one - so you DON'T HAVE to use it - but you can! :-)

     

    Of course it's a bit more work, but therefore we have our own own implementations for wheel-mouse support and page wrapping actions while scrolling etc.

     

    C-Box

     

    Date: 2006-03-06 08:11

    Sender: sirion_oef

    Logged In: YES

    user_id=1219142

     

    Could be posible put a property for change bettwen these two versions?

     

    The current version works better when there are lots of pages and lot of information, the previous version works better when are just a few pages (my case) and is not necesary a big zoom

     

    Date: 2006-03-06 01:25

    Sender: teodordProject Admin

    Logged In: YES

    user_id=332465

     

    Hi,

     

    It seems there is no perfect solution for the viewer. The current version performs better when we move from one page to another and support heigher zoom ratios, but is slower on scroll operations.

     

    The previous versions worked better with scroll, but had zoom limited to 250%, consumed more memory and were slower when changing the page.

     

    Thank you,

    Teodor

     

    Date: 2006-03-03 08:12

    Sender: sirion_oef

    Logged In: YES

    user_id=1219142

     

    i'm using the 1.5.0_6 version of java, from sun

    http://java.sun.com/j2se/1.5.0/index.jsp

     

    Date: 2006-03-03 03:29

    Sender: teodordProject Admin

    Logged In: YES

    user_id=332465

     

     

    Hi,

     

    What version of JVM are you using? We know the viewer is slower on some implementations of the virtual machine, like the IBM one.

     

    In any case, the modifications we made in the viewer are a result of this patch here, which solved some other issues, but apperently are not very good for everybody.

     

    http://sourceforge.net/tracker/index.php?func=detail&aid=1367158&group_id=36382&atid=416705

     

    Thank you,

    Teodor

     

     

    No Files Currently Attached



    User Feedback

    Recommended Comments

    A little history, first. JRViewer used to export the report page to a buffered image then display the image. At some point, this was changed to directly export the report page onto the Swing component. This approach was faster in some cases and allowed bigger zoom levels (at large zoom levels, the buffered image would require too much memory). However, this approach seems to slow the viewer in other cases.

     

    JRViewer can now dynamically switch between the two rendering approaches. The "net.sf.jasperreports.viewer.render.buffer.max.size" property can be used to specify a threshold before which buffered images will be used for rendering the report page; when this threshold is reached, the report is rendered directly. The threshold is specified in image square pixels (i.e. the threshold is reached when the image width x the image height > the max size property).

     

    By default, the threshold is zero and this means that the "direct" rendering approach will always be used. The threshold can be set to a large enough value if one wants to always use buffered images.

     

    In addition to this, the performance of the "direct" rendering approach has been improved by skipping report elements outside the clip area in JRGraphics2DExporter.

     

    The changes have been checked-in on SVN.

     

    Regards,

    Lucian

    Link to comment
    Share on other sites



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...