timm@runx.oz.au (Tim Menzies) (02/08/91)
Dear netland,
I've got a graphics application written in Smalltalk V/286. One
problem with it is that the screen redraws are a slow. I've
got a display of a X-Y plot with lots of lines/ text labels on it.
I've tried various ways to speed up the redraws. The manuals isn't exactly
helpful and so I include below a sample listing and ask the following
questions...
- would you expect that writing to a virtual form, then copying
this to the display, would speed up the redraw? If yes, then
how is this done? I've tried every variant I can think of on
setting drawLine's pen's dest/sourceForm to Display/form etc.,
etc.
- any other ideas on how to speed up the redraws on the following
sample system?
There must be a way. The standard Smalltalk window redraws are
FASTTTT. What am I doing wrong?
Tanks in advance,
--
_--_|\ Tim Menzies (timm@runxtsa.oz) "A degree proves that you can do
/ \ HiSoft Expert Systems Group, something you don't enjoy for 3
\_.--._/ 2-6 Orion Rd, Lane Cove, NSW, 2066 years. And if you get good marks,
v 61 2 9297729(voice),61 2 4280200(fax) it shows you can do it well."
--- cut here ----
Object subclass: #UNSDrawTest
instanceVariableNames:
'view form '
classVariableNames: ''
poolDictionaries: '' !
!UNSDrawTest class methods !
demo
"Give it a whirl and see what happens."
self new open! !
!UNSDrawTest methods !
comment
"
This class is a test of various methods
of speeding up a graphic redraw."!
drawLines
"Draw a line from position to position."
|pen|
pen := Pen new defaultNib: 1;
frame: view frame.
self positions pairsDo: [:last :next|
pen place: last.
pen goto: next]!
graph: rect
"Return a new graph-form for the
display."
form := Display compatibleForm
width: rect width
height: rect height.
form displayAt: rect origin.
self drawLines.
^form!
open
"open the display."
|topPane|
topPane := TopPane new label: 'redraw test';
minimumSize: (200 @ 100);
yourself.
topPane addSubpane:
(view := GraphPane new
model: self;
name: #graph:;
framingBlock: [ :box | box]).
topPane reframe: (10 @ 10 extent: 350 @ 200).
topPane dispatcher open scheduleWindow!
positions
"Return a long list of points that are
the corners of a complicated line that will
take some time to draw on the screen."
|topLeft topRight bottomLeft bottomRight
x0 y0 x1 y1 n deltax deltay positions|
positions := OrderedCollection new.
n := 20.
topLeft := view frame origin.
topRight := view frame origin +
(view frame width @ 0).
bottomLeft := view frame origin +
(0 @ view frame height).
bottomRight := view frame corner.
y0 := topLeft y.
y1 := bottomLeft y.
x0 := topLeft x.
x1 := bottomRight x.
deltax := x1 - x0 / n.
deltay := y1 - y0 / n.
x0 to: x1 by: deltax do: [:x|
y1 to: y0 by: deltay negated do: [:y|
positions add: x rounded @ y rounded]].
x0 to: x1 by: deltax do: [:x|
y0 to: y1 by: deltay do: [:y|
positions add: x rounded @ y rounded]].
^positions ! !
! Collection methods !
pairsDo: aBlock
"Message the block with all adjacent
items in the receiver, working left to
right."
|last|
self indexDo: [:next :index|
index > 1
ifTrue: [aBlock value: last
value: next].
last := next] ! !
! GraphDispatcher methods !
processControlKey: aCharacter
"Private - Cr = update."
aCharacter == Cr
ifTrue: [^pane update].
super processControlKey: aCharacter ! !klimas@iccgcc.decnet.ab.com (02/12/91)
In article <1991Feb8.102528.10392@runx.oz.au>, timm@runx.oz.au (Tim Menzies) writes: > Dear netland, > > I've got a graphics application written in Smalltalk V/286. One > problem with it is that the screen redraws are a slow. I've > got a display of a X-Y plot with lots of lines/ text labels on it. > I've tried various ways to speed up the redraws. The manuals isn't exactly > helpful and so I include below a sample listing and ask the following > questions... > > - would you expect that writing to a virtual form, then copying > this to the display, would speed up the redraw? If yes, then > how is this done? I've tried every variant I can think of on > setting drawLine's pen's dest/sourceForm to Display/form etc., > etc. > - any other ideas on how to speed up the redraws on the following > sample system? > > There must be a way. The standard Smalltalk window redraws are > FASTTTT. What am I doing wrong? One simple trick to significantly speeding up windows is to simply byte align your windows (i.e. make the X coordinate of a pane's origin an even multiple of 8, such as 0,8,16,24, etc.). I have observed a significant speedup by this simple guideline and I believe it may hold for other windowing systems also (note that OS/2 PM byte aligns your windows when you try to reposition them less than 8 pixels). Ed Klimas
pkr@media01.UUCP (Peter Kriens) (02/19/91)
> Dear netland, > > I've got a graphics application written in Smalltalk V/286. One > problem with it is that the screen redraws are a slow. I've > got a display of a X-Y plot with lots of lines/ text labels on it. > I've tried various ways to speed up the redraws. The manuals isn't exactly > helpful and so I include below a sample listing and ask the following > questions... > > - would you expect that writing to a virtual form, then copying > this to the display, would speed up the redraw? If yes, then > how is this done? I've tried every variant I can think of on > setting drawLine's pen's dest/sourceForm to Display/form etc., > etc. > - any other ideas on how to speed up the redraws on the following > sample system? > > There must be a way. The standard Smalltalk window redraws are > FASTTTT. What am I doing wrong? Unfortunately I did not see the original listing, only a reply. I could give you a few tips for speeding up general graphics. maybe you can use them. Only draw the parts that are needed. Clip the area which you know that is not changed. Draw on a bitmap and bitblit the resulting form on a redraw message. A lot of people dont know how the MVC mechanism should be used. Make a form of the largest size you are going to be using. Use this as a drawing area that is kept up to date. If you make changes that need to be shown on the screen say "self changed: #xxxx" where xxxx is the name of the graphpane. The message xxxx should then just return you form. If you have objects you show on the screen with text and graphics in it, use a form to represent these so that you don't have to rebuild this each time you redraw the screen. Buy a faster machine. If you want, you can send me your code and I can inspect it to see what is going on. Peter Kriens pkr@media01.uucp
cooper@netcom.COM (Ken Cooper) (02/20/91)
One other thing you might note: Smalltalk/V 286's graphics bitblt routines are optimized for blitting on 8 bit boundaries. It makes *quite* a difference. Ken Cooper Acumen Software
tsw@hpctdkf.HP.COM (Tom Wisdom) (02/22/91)
/ hpctdkf:comp.lang.smalltalk / cooper@netcom.COM (Ken Cooper) / 10:22 pm Feb 19, 1991 / >One other thing you might note: Smalltalk/V 286's graphics bitblt routines >are optimized for blitting on 8 bit boundaries. It makes *quite* a difference. Did Acumen rewrite the bitblt routines for Widgets/V286? If so, what kind of performance improvement did you get? Aren't you limited by the PC/AT bus width and the display adaptor's bus interface (8 or 16 bit)? >Ken Cooper >Acumen Software >---------- "LOOKING FOR FASTER, WIDER, DEEPER SMALLTALK" Tom Wisdom, Hewlett-Packard, Colorado Telecommunications Division P.O. Box 7050, Colorado Springs, CO 80933 | UUCP: hplabs!hp-lsd!hpctdlb!tsw Phone: (719) 531-4739 | ARPA: tsw@hpctdlb.col.hpcom
cooper@netcom.COM (Ken Cooper) (02/24/91)
No, we didn't rewrite any of the bitblt routines. Instead we looked for their optimization areas, and took advantage of them. Ken
tsw@hpctdkf.HP.COM (Tom Wisdom) (02/26/91)
Can you elaborate on this? Such as which operations should be avoided? Any suggestions would be appreciated. -Tom
cooper@netcom.COM (Ken Cooper) (03/04/91)
The biggest gain we got was in blitting; as I mentioned, blitting only on 8 bit boundaries made a big difference. Also, you probably already know this, but some operations are done pretty boneheadedly, like drawing rectangles and lines (as I recall, the rectangle routine was pretty funny to look at; kind of like looking at the bit manipulation routines). Good luck with it! BTW, what is CTD? I used to work in CTOS at Corporate, and that's a new acronym by me. Ken Cooper Acumen Software