mirror of
https://github.com/apache/cloudstack.git
synced 2025-12-15 18:12:35 +01:00
88 lines
3.3 KiB
Plaintext
88 lines
3.3 KiB
Plaintext
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
|