 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