Re: [Squeak-VMdev] Host windows

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

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

> On Friday 10 September 2004 10:28 am, Tim Rowledge wrote:
> > =A0So any
> > VM that buffers the window has to actually handle the paint events an=
d
> > not pass them up, and we have to remember not to put anything in the
> > image that relies on getting those events. That's all I meant when
> > refering to portability.
>=20
> Remember too that we may be rendering to something that isn't making pi=
xels.=20
> For instance, consider PDF output, or Postscript output, or the various=
=20
> OS-level (like Mac OS/X (or OS/2)) graphics APIs where you can cleanly =
render=20
> higher-level objects than pixels.
Isn't that why one would have PSCanvas etc? I'm not going to claim to
have much cleu about the care and feeding of canvases but that seems
like the intent.=20

> Now that I'm looking at Cairo I think that what is needed is:
>=20
> * maintain separate context information about each display surface
> * VM reports damage rects to image (with, of course, information about =
which=20
> display surface they're for)
> * VM reports size/visibility changes for display surfaces
> * image manages damage rects
> * Canvases are write-only and support high-level operations (like Cairo=
 or the=20
> PDF or Postscript imaging model; not too far from what we have now exce=
pt for=20
> the concept of 'current position')
> * display surfaces may be write-only; some (e.g. Form) may not be, as n=
eeded.
> * maybe a higher-level interface to OS windowing API, but this should b=
e kept=20
> separate from the display surface API (i.e. we should not be dealing wi=
th=20
> Window or Screen directly as a display surface, just with the parts tha=
t get=20
> drawn on)
> * I/O events are associated with higher-level objects like Windows.
Sounds very plausible to me. Rather like VW actually.=20


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
A)bort, R)etry or S)elf-destruct?