| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| |
| |
| |
| Delivered-To: urba-cgu@urbanet.ch |
| From: James House <james.house@medibuy.com> |
| To: Ceki Gulcu <cgu@urbanet.ch> |
| Subject: RE: Buffering issues |
| Date: Tue, 23 Jan 2001 11:38:30 -0800 |
| X-Mailer: Internet Mail Service (5.5.2650.21) |
| |
| |
| |
| Ceki, |
| |
| |
| Most of the "speed" issues can be easily solved, as demonstrated in |
| the new versions of the files that are attached, and as described |
| here: |
| |
| |
| The "drawing" of the panel is time consuming. And let's face it: we |
| will never build a swing component that can re-draw itself thousands |
| of times per second - nor could the human eye keep up with that anyway |
| (60-ish redraws per second is the limit of what most humans can |
| perceive). |
| |
| |
| I think you'll agree that regardless of which choice of swing |
| components, the issue of not being able to draw more than 100 times |
| per second (if that) will be a constant. |
| |
| |
| Possible solutions to wasting a lot of time redrawing are: |
| * Redraw every N messages |
| * Redraw every N milliseconds |
| * Redraw when a message of a high priority is received |
| * Only redraw if the changes (new messages) are visible (depending on |
| scroll-bar position) |
| |
| |
| |
| I made some very small changes (which are some of what I outlined in |
| the previous e-mail as things on the to-do list), and you should be |
| able to see a great difference in performance. |
| |
| |
| In general the changes are: Use a "queue" to asynchronously deliver |
| the messages to the panel for updating, rather than having the calling |
| thread (the one generating the log message) be responsible for |
| re-drawing the panel - this frees up the thread to continue on without |
| waiting for the logging mechanism. The "queue" has a thread that |
| wakes up every N milliseconds, or when a message of a specified |
| priority arrives. It then delivers all queued messages to the panel, |
| which then redraws ONCE for the entire batch of queued messages IF the |
| new messages are visible in the display. |
| |
| |
| With the "tail" mechanism turned on (so that any new set of messages |
| forces a redraw, because the last message is always visible), the |
| panel can now log about a thousand messages in 1 second. With tail |
| turned off (so that redraw is only required if the panel is showing |
| the space the new messages will be printed), it can receive over a |
| 100,000 messages in just a few seconds. Also, most of the flicker is |
| already eliminated. |
| |
| |
| Again, everything in the code is really "roughed in" - just there to |
| give the general idea, not necessarily to do things in the best way - |
| but I really feel that this kind of solution is what you'll have to |
| end up with in the long term. |
| |
| |
| James |