FormCanvas cleanup (was Re: [Squeak-VMdev] Host windows)

[Tim R. <ti...@su...>]

In message <200...@bi...>
          Ned Konz <ne...@bi...> wrote:

> > and  FormCanvas>flushDisplay 
> > which again talks to Display rather than the target form.
> 
> And isn't called, and should be removed.
Easy :-) Even I can do that.
> 
> > It's  understandable that this might be done with only a single window,
> > though it seems a waste of time when the target form is not the Display.
> 
> But forceDamageToScreen and flushDisplay are only used (should only be used, 
> anyway) when it's clear that we're rendering to the Display.
If it's that important perhaps it would be better to have a subclass
(DisplayCanvas) that knows this. FormCanvas really ought to be what it
claims to be, a canvas for displaying upon a Form.

Whilst digging in to how remove Display dependency from FormCanvas
I find some oddness. One of the methods using Display is
FormCanvas>showAt: pt invalidRects: updateRects
	| blt |
	blt _ (BitBlt current toForm: Display)
		sourceForm: form;
		combinationRule: Form over.
	updateRects do:
		[:rect |
		blt sourceRect: rect;
			destOrigin: rect topLeft + pt;
			copyBits]
and clearly this is a time wasting no-op when 'form' == Display. It
might possibly be a strange way of forcing out the damage rectangles
via BitBlts use of #showDisplayBits? It's obviously a touch more useful
when form ~= Display but if that is the case why would we want to blit
to Display anyway?

#showAt:invalidRects: is only really sent by
WorldState>displayWorld:submorphs: and then only if deferredUpateMode
is false.
That in turn depends upon #doDeferredUpdatingFor: which seems
like mostly work that could be done at some initialisation stage rather
than check every update cycle? In particular it uses
	PasteUpMorph disableDeferredUpdates ifTrue: [^ false].
which appears to be a dead path these days. The only method that might
set this to false is PasteUpMorph class>disableDeferredUpdate: which is
a) tagged as old, Dan's, and from context possibly related to his
weathermachine hardware
b) commented in such as way as to define itself as redundant. To whit,
explaining that deferring is used by Morphic to do a sort of
double-buffering and that direct-write screens would use a different
canvas with a buffer. Thus no need for the classvar etc.... Maybe it's
so old it predates the full usage of the VM update flag?

Thinking of said flag, I spotted a number of comments that infer that
somebody assumed that it was a platform specific primitive, which it
isn't.  #primitiveDeferDisplayUpdates has no conenction to any platform
setting or function. It _could_ have if that was really intended.
WorldState>doDeferredUpdatingFor: and
WiWPasteUpMorph>doDeferredUpdating are two such cases.
DisplayScreen>deferUpdates also comments
" If this underlying platform doesc not support deferred updates, this
primitive will fail"
which is silly since the prim always suceeds (unless the arg is
non-boolean) and deferred updates are always claimed to be supported;
another test in each of the doDeferred* mentioned before can be dropped.
If we could allow ourselves to update the prim to return the previous
value itself we could drop a silly method and a classvar in
DisplayScreen.

Later in doDeferredUpdatingFor: we have a tacky test for whether the
canvas is a FormCanvas on Display. If aWorld == World and the canvas is
not a FormCanvas etc, we set it to so be. Couldn't this be better done
in an init method?  Likewise the later line for MVC stuff. This is
actually a problem if we want to use a FormCanvas with a form ~=
Display since it will get reset the first time we try updating it!
Should this sort of side-effecting be done here? We're getting way past
my knowledge of how all this convoluted spaghetti works.

So, deferredUpdateMode is almost certain to be true. If it is always
true, the 'canvas showAt:... could be dropped completely and the issue
of wastefully displaying Display on Display avoided completely rather
than just by accident.

Sheesh, all that for one method. On to the next one.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Programmer: One who is too lacking in people skills to be a software engineer.