Morphic graphics, Displaying fonts & canvases

Andreas Raab andreas.raab at gmx.de
Sat Apr 21 05:03:55 UTC 2007


sig wrote:
> 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?

That depends on whether you mean the question philosophically or 
practically. Philosophically you're right, but practically, there is 
really no need for a DisplayMedium.

> 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.

Again, depends on whether you want to be practical or philosophical. 
Practically speaking I have often dealt with files without spending a 
single thought on the file system. In many cases the files we pass 
around are encapsulated enough that you really cant't tell whether that 
"file" comes from a file system or whether it's just a stream of bytes. 
The same goes for Canvas and DisplayMedium; canvas is a fairly 
high-level abstraction such that its interface can be implemented in 
various different ways, some of which may not require a display medium 
at all.

>> 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:

I said "little to no" assumptions which in English means that there may 
be some assumptions but that they are not that important. You found one 
of those, correct, but this is no contradiction of my statement.

> 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?

Only if they are relevant to this discussion. I'm sure there are a few 
more places where such dependencies exist but they are easy to fix if 
one wanted to (I know this because I have implemented canvases that 
didn't use a display medium).

> 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?

Sending #form would me meaningless (and the PSCanvas should consequently 
answer nil) but it could still answer the color at 0 at 0 if that were 
required. It would be slow, yes, but it could be done merely by 
executing the drawing commands and recording the intersections with 0 at 0 
(depending on your tradeoffs that may be perfectly acceptable).

>> 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?

Well, to be honest I'm not sure ;-) You seem to making more of a 
philosophical point about "how things ought to be" but if you have 
practical issues maybe we should discuss those instead?

> Because currently Canvas can't give me a ways of fully controlling
> drawing operations for Display. Thats why.

Then maybe we should talk about the concrete problems you have. Like, 
what are you trying to do and where does Display get in the way? We have 
done a lot of this in Croquet in the past and I'm pretty sure I could 
give you a bit of advice on addressing the problems you have.

Cheers,
   - Andreas




More information about the Squeak-dev mailing list