On 21/04/07, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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.
>
The difference liying is when at philosophical level you stating one,
but in practice you follow different rules. This leads to things when
you code become unmanageable and which is hard to improve.

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

Ok i follow your point. Then we can define Canvas as intermediate
object which pipelines a primitive commands to some kind of medium.
One way or another canvas in its working state must be connected to
its medium to make possible to produce anything. Yes, you can fully
encapsulate meduim in canvas and dont rely on other objects/classes to
produce output but tell me then what will happen when you create two
different canvases to draw on the same medium and when you can't
control the order in which drawing commands will be issued?
Imagine two canvases open same postscript file or printer and write
there without knowing about each other.
And its obvious, that to prevent such behaviour we need an abstract
class which represents a single unique medium and then it can control
the ways of how and when you can draw on it, simply by answering a
#getCanvas message.
Maybe this is a different angle, but for DisplayScreen its the right
angle. Correct me if im wrong.

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

But for my purposes i need to replace Display with own instance. There
is no way how to avoid that. I need all the drawings be redirected to
OpenGL. And if you know, stating that OpenGL display medium are
rectangular area of pixels leads to great limitations and drawbacks
which will prevent me from using OpenGL at full throttle.
Of course i can fix this. But this will be not elegant solution
because of wrongly designed  interactions protocol between canvas and
display medium.

>
> 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.
>
There are many of them. I can't remember all of them now but for the
future i will know where to ask :)

Take a look at senders of #defaultCanvasClass and its implementation
the most frequent its use is:
Display defaultCanvasClass extent: extend depth: depth

currently i have no choice but return a FormCanvas, but for future i
think to remove this method at all and change its users to use caching
canvas.

Something like this:

cache := Display getCanvas asCachingCanvas

..issue drawings to cache ..

cache atSourceRect: rect displayAt: aPoint