-
Bug
-
Resolution: Not an Issue
-
P2
-
None
-
1.4.0
-
sparc
-
solaris_8
This is another Bug in the series of Bugs for Deutsche Boerse Application problems (Currently escalated in Esc# 536043 (Ref# 36537521) Deutsche Boerse, (Bug# 4473503)). It is opened by request and will be escalated seperately.
Problem Description:
Painting a popup window is very slow.
It takes about 5 secs on an u10/ sol 8 compared to 1 sec on a comparable wintel nt pc.
About the application
A graphical user interface has been developed using Java 1.3.1/1.4 to visualise
financial market data sent by an exchange and to allow users to submit requests
to the exchange. JNI is used to communicate with an API written in C, which
connects to the exchange. Visualisation is mainly done using swing tables with
some changes applied e.g. to the repaint manager to improve performance. The
application consists of about 3000 classes, uses about 20 threads and typically
consumes about 100 to 200 MB (as seen from OS`s task manager or similar
utilities) of memory depending on the amount of data processed by the
applciation. Table sizes may be up to approx 60 columns and several thousand
rows with table cells displaying numeric and/or alphanumeric data. Peak rates
of incoming events via JNI are up to 300 events/sec. All of these events have to
be processed by the application quickly in order to update application data
structures and ensure data integrity. Table cells visible on screen are updated
with rates anything from occasinally to up to three times a second. Upon update
of a cell its style (background colour, font colour) is changed. While tables
are updated users may click into a cell or open context sensitive menus
pointing at a cell to open additional windows to submit requests. These windows
typically consist of about 15 to 20 swing text fields, labels, and buttons which will be enabled, disabled, coloured, filled or cleared dynamically depending on the contents of individual text fields. Users usually fill one or two remaining
textfields via the keyboard and hit a button or key to submit a request.
Problem Description:
Painting a popup window is very slow.
It takes about 5 secs on an u10/ sol 8 compared to 1 sec on a comparable wintel nt pc.
About the application
A graphical user interface has been developed using Java 1.3.1/1.4 to visualise
financial market data sent by an exchange and to allow users to submit requests
to the exchange. JNI is used to communicate with an API written in C, which
connects to the exchange. Visualisation is mainly done using swing tables with
some changes applied e.g. to the repaint manager to improve performance. The
application consists of about 3000 classes, uses about 20 threads and typically
consumes about 100 to 200 MB (as seen from OS`s task manager or similar
utilities) of memory depending on the amount of data processed by the
applciation. Table sizes may be up to approx 60 columns and several thousand
rows with table cells displaying numeric and/or alphanumeric data. Peak rates
of incoming events via JNI are up to 300 events/sec. All of these events have to
be processed by the application quickly in order to update application data
structures and ensure data integrity. Table cells visible on screen are updated
with rates anything from occasinally to up to three times a second. Upon update
of a cell its style (background colour, font colour) is changed. While tables
are updated users may click into a cell or open context sensitive menus
pointing at a cell to open additional windows to submit requests. These windows
typically consist of about 15 to 20 swing text fields, labels, and buttons which will be enabled, disabled, coloured, filled or cleared dynamically depending on the contents of individual text fields. Users usually fill one or two remaining
textfields via the keyboard and hit a button or key to submit a request.
- relates to
-
JDK-4473503 Need ability to schedule events at same priority as awt painting events
-
- Closed
-