Jose Emilio Labra Gayo <[EMAIL PROTECTED]> writes:
> I am using the Graphics library and I have 2 questions:
> (I am running HUGS 1.4 (970719) on Windows 95)
> - If I call "polyline" with a single point it does strange things (the
> following program shows a window and closes it inmediatly). Is it normal?
In Win32, PolyLine returns an error code if you pass it an array with <2
points in it. The Graphics library catches that error code and propagates
it up to the Picture drawing code which catches the error and aborts the
program. (Similar constraints apply to the bezier functions and the other
polygon functions.)
There are a number of possible fixes:
1) Do nothing - probably not a good choice since it sounds like people
are finding it confusing.
2) Print a useful error message.
We've just rewritten the Win32 interface (using GreenCard 2). This
revised interface (which isn't ready for release yet) gives much
better error messages - we can make sure that we actually disp0lay them
on the screen.
3) Change the semantics of polyline so that lists of 0 or 1 Points do
nothing rather than producing an error.
This is easy to implement - the only question is whether it is the
Right Thing to do. Would this mask genuine programming errors
(leading to confusion) or would it lead to a simpler graphics
calculus?
In this case, I think it's probably the right thing to do. For bezier's
(which require something like 3n+1 points), we should probably
continue to raise an error code.
> - Suppose I want to draw a program who prints infinite lines
> (until I type interrupt it). For example:
>
> doLines = [line p1 p2 |(p1,p2) <- zip pts (tail pts) ]
> where pts = map f [0..]
> f x = (x+1,x+1)
>
> How can I print then on the screen. I tried with "overMany" but it tries
> to evaluate the list and it doesn't print anything.
The graphics library draws the entire picture and then bitblts it onto
the screen in one go. Since your picture contains an infinite number
of lines, it obviously takes an infinite amount of time to draw it.
The right approach is to use not just one picture but a sequence of
pictures which you draw to the screen at regular intervals.
Sadly, "animations" like this aren't very well supported by the
graphics library - as the picture gets bigger and bigger, the redraw
time will get longer and longer. We could have avoided this problem
by buffering Pictures in a bitmap (and using a different
implementation for addToPicture) - but that wouldn't allow us to
resize windows.
The only way we can see of fixing these problems is to expose more of
the underlying machinery (bitmaps, device contexts, etc) and abandon
the simple declarative semantics of Pictures in favour of a purely
operational semantics.
Alastair
ps If it's animations you're wanting, give Fran a shot - it was designed
for the purpose.
