Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!agate!eris!doug
From: doug@eris (Doug Merritt)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <8928@agate.BERKELEY.EDU>
Date: 19 Apr 88 06:52:19 GMT
References: <1367@hubcap.UUCP> <3626@cbmvax.UUCP> <8712@agate.BERKELEY.EDU> <3641@cbmvax.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: doug@eris.UUCP (Doug Merritt)
Organization: University of California, Berkeley
Lines: 132

Before getting into specifics, thanks, Hedley, for taking the trouble
to research your response. With an exception or two I address below,
but don't worry, there's no flames.

[ Hedley, me, then Hedley again: ]
>>>The FlickerFixer design is not flawed given the boundary values of the
::Incorrect. The software may *already* be synched to a 30hz display
>	Shame on you. I state some premises, and draw a conclusion based
>on those premises. You edit the premises out, and then out of context
>claim I am incorrect.

I didn't realize that was the case; I must have misunderstood your
wording. Sorry! And your example of Intuition moving the pointer at a
60hz rate is well taken.

But to return to the *original* point: simply that flickerFixer would
work better if it *only* merged the odd and even scan fields of a single frame.

This would not break *existing* software that did interlaced animation at
a 30hz update rate. By which I mean software which is taking advantage
of 400 lines of detail, which can be animated at a maximum 30hz rate.
The example of Intuitions pointer is different; if you're animating
at a 60hz rate then you only have half the detail.

Also my suggestion for an improved design would at least allow the
possibility for, e.g. Intuition to precompensate in a future release
(using motion blur, presumably. Or a simple 30hz update rate).

I'll hit this from a different angle again below, possibly more clearly.

>Did I ever tell you that you have an uncanny method of breaking sentences
>into two paragraphs when it lets you end the first paragraph with a punch ?

Interesting. Is that good or bad?

>Paraphasing, you state:
>	IF you write software with the knowledge that your interlaced 
>	display should only change 30 times a second, AND your scan 
>	converter buffers two whole feilds, AND you happen to swap buffers 
>	on the correct feild, then you have the ideal solution.

No. "happen to swap" isn't right...I'm claiming that anything that
animates a full 400 lines of detail at 30hz (which some people certainly
do!) is already swapping on the correct field, and that *this* is
what fF breaks.

>=	[ Further derivations of theroms based on afformentioned
>=	inconsitant logic deleted. ]

Come on now. Let me try again from another point of view. Whatever
is shown on an interlaced display is either 1) being updated at a 60hz
rate, in which case fF is doing the best it possibly can, and any
flicker fixing design would merge the previously separate images, or
else 2) the interlaced display is being updated at 30hz because all
400 lines are significant, and the software is ignoring the fact
that it takes two fields to make up a full frame, in which case
fF is flawed because it merges *all* adjacent fields, not just the
correct even and odd fields of each frame.

Both techniques can be found in existing software. fF is perfect
for case #1, it is flawed for case #2.

>=By the way, the reason for the approximate range of values (40-45hz) [...]
>=it's because the CFFR depends on the contrast of the images. Low contrast,
>=as we all know by now, flickers less. High contrast requires a higher
>=display rate. Once you get above 45hz you're generally considered safe
>=even with high contrast.
>
>Flicker perception depends not only on contrast, but brightness as well. 

True. Since we're on the subject, thanks for the clarification.

>The reason films in theaters do not flicker is that they are shown in a 
>darkened enviroment. 

Oops, nope, the dark *increases* contrast...but it still happens to
be in the right range.

>It went on further to note that some enviroments 'often employ a
>very high screen brightness which creates noticable flicker although
>shutter frequency is maintained at the required 48 interuptions
>per second.'

True. Note above I said "above 45hz you're generally considered safe".
I put the word "generally" in there to avoid going into a bunch of
extraneous detail (this *is* a digression, after all). In truth, the
absolute maximum rate for the critical flicker fusion rate is higher
than 45hz. But it takes pretty high brightness and contrast levels
for that to be a problem. I've forgotten the exact maximum but
it's kind of academic. Computer displays don't get that bright.

>I go further to note that 50 Hz. CRT displays typically flicker.

Yes, and note that they are interlaced, giving a 25hz flicker rate!
You're thinking as if they are non-interlaced. (The Encyc. Brit. discusses
these European standard interlaced displays, too.)

>So, even though my arguements may be based on 'bad recollection', yours
>use references that may have their place in academia, but do not apply
>to the enviroment of this discussion, IE computer displays.

As I indicate above, incorrect again. Sorry to gloat, but I'm still
right on target. Actually, I love to gloat. :-)

[ my comments about 120hz displays deleted ]
>	Ok, you can scroll faster. Like maybe twice as many lines per
>second. Question:  Do you want to smooth scroll really fast, ( like twice 
>as fast ), or see twice as much information on the screen  ( like 400 lines
>instead of 200 ) ?

The point is that it's nice to have a choice between the two,
not have it made for you. The current Amiga design allows 200 line
animation at 60hz, with flicker, or 400 line animation at 30 hz,
with flicker dependent on image. (Yeah, you said something similar
to this a little later, I know. I can't include *everything*).

As to the relative values of temporal vs. spatial bandwidth in
general, why, it depends on the application. Again, see the
MIT Media Lab work.

>	Unless memory bandwidth suddenly becomes much less expensive than
>it is now, doubling the display resolution in spatial or color domains
>will take precedence over the temporal domain. You can yell and kick all
>you want, but bandwidth is bandwidth, and ( excepting a small number of
>specialized uses ), spatial and color bandwidth will take precedence over
>temporal bandwidth.

Oh, I agree. And this doesn't contradict anything I said. I already
know that; you're acting like I said something dumb. So far everything
you've tried to contradict has withstood your fire.
	Doug Merritt		doug@mica.berkeley.edu (ucbvax!mica!doug)
			or	ucbvax!unisoft!certes!doug
			or	sun.com!cup.portal.com!doug-merritt