Morphic graphics, Displaying fonts & canvases

sig siguctua at gmail.com
Fri Apr 20 17:33:13 UTC 2007


On 20/04/07, Andreas Raab <andreas.raab at gmx.de> wrote:
> You are looking at the problem from the wrong angle. If you want to
> change the way morphs are drawn you need to be looking at replacing
> Canvas, not DisplayMedium.
>
The canvas is 'The tool' with which you can draw on medium.
Given a medium you need a canvas to draw on it.
Is this correct?
I can't imagine a canvas without medium. Can you imagine a file
without file system? File system establishes rules on how its
organized internally, while for outer world all file systems have
common protocols like open file , write to it, close it.
As for display medium: we have to pass primitive commands to canvas
and it acts as bridge between medium internal state and common
protocol.

> Canvases generally make little to no assumptions about their medium;
> they use abstract drawing commands (lines, rectangles, polygons) instead
> of using BitBlt directly. They also encapsulate their backend (which may
> or may not be a DisplayMedium). Some canvases (like the one used by the
> remote Nebraska sharing protocol) don't even have DisplayMedium to
> operate on. Etc.

you say no assumptions? then what is it:

Canvas>>form
	^ Display

first it assumes that canvas have Form, second it assumes that this
form is a current Display. do you want more examples?

Canvases, in one way or another, must have connection to their medium
- they must know how to control it, e.g. what commands to send to draw
line/circle on it e.t.c. But Morphs cannot even think about how or
where they draw themselves beyond Canvas protocol. And can't even
think about retreiving some kind of form.
As i said before - drawing is one way road!
Take a PostScript canvas which generating a PS file from commands you
pass to it. What the meaning of sending #form to it? Do the postscript
file have pixel at 0 at 0 , can you read its value?

>
> In short: If you look to change the way morphs are drawn, look at Canvas
> and its subclasses. DisplayMedium is the wrong place for that.
>
I dont know if you read my mail to the end. I implemented GLCanvas
which is a subclass of Canvas. And  why do think im talking about
DisplayMedium?
Because currently Canvas can't give me a ways of fully controlling
drawing operations for Display. Thats why.



More information about the Squeak-dev mailing list