Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4046446

ScrollPane limitation for large Canvas

XMLWordPrintable

    • beta
    • generic, x86, sparc
    • generic, solaris_2.5.1, windows_nt, windows_xp

      The problem we are having, and I'm sure many other users of
      AWT will run in to this eventually, is this: We have several
      components that we created using the ScrollPane: i.e.
      ListControl, TreeControl, and GridControl. These
      components are designed to display large amounts of data
      - which is typical in real business applications. In Win32
      (Windows95/WindowsNT), the ScrollPane currently limits
      the client component to roughly 32000 pixels tall and/or
      wide. This works out to about a 1600 record limit in a
      GridControl (depends on font sizes), which is an
      unacceptable limitation.
           What this boils down to is this: A user can only see a
      small portion of the data they want to display in a Grid, List,
      or Tree. For a business database application development
      tool, this is a STOP SHIP bug. JBuilder is a business
      database development tool. We need this fixed right now.
           The fix is pretty straightforward, and has to be rolled into
      the Win32 implementation of AWT. Win32 uses a short to
      represent the scroll position in the native Windows Scrollbar
      widget. If the client component is larger than this, a scaling
      factor needs to be factored in for all messages going
      between the Java code and the native Win32 code. If fixed
      correctly, there will be no compatability impact. Users' Java
      code will simply not know about the pixel limitation under
      Win32 - it should be nicely hidden.
      ----------------------------------------------
           The test case is VERY simple to create, so I will merely
      describe what is actually happening here... In Win32, the
      native scrollbar uses a short int to represent the scroll
      position. It is very common practice in Win32 programming
      to subclass the scrollbar and incorporate a scaling factor
      when the range value exceeds the short int limit (32K). The
      ScrollPane's peer object does not have this scaling factor
      built in, so it is limited to scrolling 32 thousand pixels in any
      direction. This equates to roughly 1500 records (depends
      on text height) on our GridControl or ListControl, which is
      typically far below the total number of records being
      displayed in a data table... this is a very nasty blocking bug
      for us - and we cannot work around it without changes to the
      native code in AWT for Win32.
           To create a test case, put a simple subclass of Panel in a
      ScrollPane, and return a figure larger than 32000 pixels wide
      and/or high in getPreferredSize(). The ScrollPane has
      serious problems with this case - and certainly shouldn't.
      ----------------------------
      Please see the attachment for a reproduciable test case in Solaris.
      This program displays the labels incorrectely in ScrollPane Panel.

      ----------------------------
      Apr 23, 97: Customer is requesting a Work Around.

      Name: krT82822 Date: 10/14/99


      Hi Java Creators!
      The Bug related to Scrollpane supporting Large Canvases was
      first reported in April 1997. We had been told that it would be
      fixed in 1.2 release. But it was not. This is a really serious
      bug. Do not consider the severity of the bug based on number of
      votes. This wasted lot of our development time. Why do not you
      fix the existing bugs and go for a newer version? Ofcourse we
       accept that it would be great if java has all current Technologies
      in it. But if you have bugs then developers would loose interest
      in Java. Definitely we should inform known bugs through BugParade.
      But those bugs should not be there for ever. Are you seriously
      trying on the bugs to which you have mentioned the status as in
      progress (for example 4046446)? Similarly when we run an executable,
      through C or C++ execl call, it would be executed as if it was
      run from command line. It would take inputs from keyboard and
      flush output to console window. Why should we get streams of the
      process and manipulate them in Java when we do the same through
      Runtime's exec? I felt so unhappy for this. Please reply for this
      mail if you are really concerned about developer's plight. After
      all i am not asking to improve its performance. I tested Hotspot
      Client side and Server side JVM's. Felt JIT compiler better. I do
      not mind for this.

      regards,
      syam
      (Review ID: 96554)
      ======================================================================

            dmikhalksunw Denis Mikhalkin (Inactive)
            duke J. Duke
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: