Re: [Squeak-VMdev] Host windows

[Ned K. <ne...@bi...>]

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

Remember too that we may be rendering to something that isn't making pixels=
=2E=20
=46or 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 rend=
er=20
higher-level objects than pixels.

That we occasionally need to read back pixels for operations like doing scr=
een=20
captures or to make shadow forms for hit testing isn't much of a reason to=
=20
clutter the rest of the API with the ability to do this. Clearly, we can ju=
st=20
render to a separate bitmap for those cases.

We can ignore roundCornersOf: given a graphics model (like Cairo) that=20
actually knows how to draw round rectangles.

Now that I'm looking at Cairo I think that what is needed is:

* maintain separate context information about each display surface
* VM reports damage rects to image (with, of course, information about whic=
h=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 except f=
or=20
the concept of 'current position')
* display surfaces may be write-only; some (e.g. Form) may not be, as neede=
d.
* maybe a higher-level interface to OS windowing API, but this should be ke=
pt=20
separate from the display surface API (i.e. we should not be dealing with=20
Window or Screen directly as a display surface, just with the parts that ge=
t=20
drawn on)
* I/O events are associated with higher-level objects like Windows.

=2D-=20
Ned Konz
http://bike-nomad.com