Menu
▾
▴
squeak-vmdev
|
From: Tim R. <ti...@su...> - 2004-09-09 20:05:19
|
(Mostly to Andreas but it affects several people and probably interests more) John passed on to me (briefly, on a bad cellphone link, so excuse any misunderstandings) the comment about hooking into the forceDamageToScreen/forceDisplayUpdate instead of into the displayBitsOfLeftTopRightBottom end of copyBits (et al.). Excellent suggestion; it avoids the unpleasantness of how to check to see if this is a Display or host window within a rather common operation. (For other people, my first and actually functional hack, was to extend displayBitsOfLeftTopRightBottom such that any bitblt to a host window would trigger the ioShowDisplay mechanism just as Display does now. It works great but meant adding a hopefully-fast way to check for 'destination is some kind of host window'. Ugly, limits you to one class etc but it does make it really simple to display stuff on the extra windows since any bitblt at all with the window as a dest will cause an update immediately) Moving the window updating to a plugin call attached to forceDamageToScreen means it can work with the Canvas mechanism. However, I have queries about some details her since I have no prior experience with doing anything to canvases. a) WTF are canvasss used? So far as I can work out the WorldState has a canvas which is a FormCanvas on the Display. So far so good but they also seem to be used in a few other places and that confuses me because ther is a good bit of code that looks like it very explicitly wants Display to be the target form. See for example WorldState>forceDamageToScreen which explicitly does Dispaly forceDamageToScreen rather than form.... and FormCanvas>flushDisplay which again talks to Display rather than the target form. It's understandable that this might be done with only a single window, though it seems a waste of time when the target form is not the Display. b) Which canvas to use? It looks like FormCanvas is the best candidate already in the system. We could subclass to make the assorted force... messages go to our host window DisplayScreen analogues but then BalloonCanvas and other subclasses of FormCanvas would need sometinhg done. If I've understood it, we could consider changing FormCanvas to send all those force... messages to 'form' instead and then the 'form' could be an instance of HostWindow and we pass them on to the HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but they all seem a bit ugly to me. c) Once we have a canvas talking to the HostWindowPlugin, we open a host window, display something on it, force the damage to screen (well, window) and it's supposed to appear on the glass. Many of us need to process pixels and we have that code in the VM so we can leverage that with (probably) a few mods to factor it not to assume getting the Display oop from specialObjectsArray. Pretty soon the OS is going to send in a paint/expose type event for that window and current code will fail. All the copies of platform code I have (a bit old but probably not horribly out of date) handle a paint by calling fullDisplayUpdate (Ian has a nice little optimisation to use any paint event clipping rectangle) which explcitly gets the bitmap from the Display oop. Clearly this isn't going to do any updating of other windows. As it happens, RISC OS is ok with this due to a side effect of how I have to keep a backing bitmap for each window. All I have to do is map from the incoming window handle to the actual host bitmap and display some of that. No problem except for the 'waste' of memory. If you want to get the latest bits from inside ObjectMemory we will need a map from host window handle to squeak bitmap oop. Easy way is to have an array held by specialObjects that has the oops of the bitmaps used by all open host windows. How else might one handle paint type OS events? d) my knuckles hurt. enough tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Useful random insult:- Afraid she'll void her warranty if she thinks too much. |
|
From: Ned K. <ne...@bi...> - 2004-09-09 20:36:41
|
On Thursday 09 September 2004 1:05 pm, Tim Rowledge wrote: > (Mostly to Andreas but it affects several people and probably interests > more) > > John passed on to me (briefly, on a bad cellphone link, so excuse any > misunderstandings) the comment about hooking into the > forceDamageToScreen/forceDisplayUpdate instead of into the > displayBitsOfLeftTopRightBottom end of copyBits (et al.). Excellent > suggestion; it avoids the unpleasantness of how to check to see if this > is a Display or host window within a rather common operation. > > (For other people, my first and actually functional hack, was to extend > displayBitsOfLeftTopRightBottom such that any bitblt to a host window > would trigger the ioShowDisplay mechanism just as Display does now. It > works great but meant adding a hopefully-fast way to check for > 'destination is some kind of host window'. Ugly, limits you to one > class etc but it does make it really simple to display stuff on the > extra windows since any bitblt at all with the window as a dest will > cause an update immediately) > > Moving the window updating to a plugin call attached to > forceDamageToScreen means it can work with the Canvas mechanism. > However, I have queries about some details her since I have no prior > experience with doing anything to canvases. > > a) WTF are canvasss used? So far as I can work out the WorldState has a > canvas which is a FormCanvas on the Display. Canvas is a protocol that is used to draw things. We have different Canvas types for different purposes, from rendering on Forms directly, to transmitting drawing commands remotely, to creating Postscript. Assuming that a Canvas is anything in particular is asking for trouble. I am making a new kind of Canvas that is an interface to the Cairo library; Cairo provides back-ends for host window display surfaces, for bitmaps in memory, for PDF output, and for OpenGL textures. > So far so good but they > also seem to be used in a few other places and that confuses me because > ther is a good bit of code that looks like it very explicitly wants > Display to be the target form. See for example > WorldState>forceDamageToScreen which explicitly does Dispaly > forceDamageToScreen rather than form.... Probably WorldState should talk to its canvas instead of assuming Display. All canvases understand "forceToScreen: rect"; this should be used instead. It is likely that we'd want to have a World that lives in some other kind of Canvas. > and FormCanvas>flushDisplay > which again talks to Display rather than the target form. And isn't called, and should be removed. > It's understandable that this might be done with only a single window, > though it seems a waste of time when the target form is not the Display. But forceDamageToScreen and flushDisplay are only used (should only be used, anyway) when it's clear that we're rendering to the Display. > b) Which canvas to use? It looks like FormCanvas is the best candidate > already in the system. We could subclass to make the assorted force... > messages go to our host window DisplayScreen analogues but then > BalloonCanvas and other subclasses of FormCanvas would need sometinhg > done. If I've understood it, we could consider changing FormCanvas to > send all those force... messages to 'form' instead and then the 'form' > could be an instance of HostWindow and we pass them on to the > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but > they all seem a bit ugly to me. Have you looked at ExternalScreen and ExternalForm? > c) Once we have a canvas talking to the HostWindowPlugin, we open a > host window, display something on it, force the damage to screen (well, > window) and it's supposed to appear on the glass. Many of us need to > process pixels and we have that code in the VM so we can leverage that > with (probably) a few mods to factor it not to assume getting the > Display oop from specialObjectsArray. Pretty soon the OS is going to > send in a paint/expose type event for that window and current code will > fail. All the copies of platform code I have (a bit old but probably > not horribly out of date) handle a paint by calling fullDisplayUpdate > (Ian has a nice little optimisation to use any paint event clipping > rectangle) which explcitly gets the bitmap from the Display oop. > Clearly this isn't going to do any updating of other windows. As it > happens, RISC OS is ok with this due to a side effect of how I have to > keep a backing bitmap for each window. All I have to do is map from the > incoming window handle to the actual host bitmap and display some of > that. No problem except for the 'waste' of memory. If you want to get > the latest bits from inside ObjectMemory we will need a map from host > window handle to squeak bitmap oop. Easy way is to have an array held > by specialObjects that has the oops of the bitmaps used by all open host > windows. How else might one handle paint type OS events? > > d) my knuckles hurt. enough > > tim > -- > Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim > Useful random insult:- Afraid she'll void her warranty if she thinks too > much. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev -- Ned Konz http://bike-nomad.com |
|
From: Andreas R. <and...@gm...> - 2004-09-09 21:44:07
|
Hi Tim,
> > a) WTF are canvasss used? So far as I can work out the WorldState has a
> > canvas which is a FormCanvas on the Display.
>
> Canvas is a protocol that is used to draw things. We have different Canvas
> types for different purposes, from rendering on Forms directly, to
> transmitting drawing commands remotely, to creating Postscript.
Correct. Unfortunately the current Canvas protocol is (how shall we say...)
historically grown ;-) IOW, it doesn't really provide the neat high-level
abstraction that we'd like to have.
> > So far so good but they
> > also seem to be used in a few other places and that confuses me because
> > ther is a good bit of code that looks like it very explicitly wants
> > Display to be the target form. See for example
> > WorldState>forceDamageToScreen which explicitly does Dispaly
> > forceDamageToScreen rather than form....
>
> Probably WorldState should talk to its canvas instead of assuming Display.
Likely yes.
> All canvases understand "forceToScreen: rect"; this should be used
instead.
Yes. It might also be interesting to check out Tweak's displayWorld
implementation - here all of the Display related operations are routed
through CWorldPlayer's display variable (and display really could be any
kind of drawable surface such as a window).
> > b) Which canvas to use? It looks like FormCanvas is the best candidate
> > already in the system. We could subclass to make the assorted force...
That's what I would do (and have done - see CTransformCanvas).
> > messages go to our host window DisplayScreen analogues but then
> > BalloonCanvas and other subclasses of FormCanvas would need sometinhg
> > done. If I've understood it, we could consider changing FormCanvas to
> > send all those force... messages to 'form' instead and then the 'form'
> > could be an instance of HostWindow and we pass them on to the
> > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but
> > they all seem a bit ugly to me.
This (the effect of wanting to use BalloonCanvas etc) is actually one of the
reasons why a distinction of the responsibilities of drawing protocol
(Canvas) vs. display surface (Window) can be advantageous. By the end of the
day, if you have a native window which has a form to display all you need is
to vector forceToScreen: and getCanvas appropriately (not counting the
various fixes in the rest of the system).
> Have you looked at ExternalScreen and ExternalForm?
Bad examples for this case. Native windows are *much* simpler.
> > c) Once we have a canvas talking to the HostWindowPlugin, we open a
> > host window, display something on it, force the damage to screen (well,
> > window) and it's supposed to appear on the glass. Many of us need to
> > process pixels and we have that code in the VM so we can leverage that
> > with (probably) a few mods to factor it not to assume getting the
> > Display oop from specialObjectsArray. Pretty soon the OS is going to
> > send in a paint/expose type event for that window and current code will
> > fail. All the copies of platform code I have (a bit old but probably
> > not horribly out of date) handle a paint by calling fullDisplayUpdate
> > (Ian has a nice little optimisation to use any paint event clipping
> > rectangle) which explcitly gets the bitmap from the Display oop.
> > Clearly this isn't going to do any updating of other windows. As it
> > happens, RISC OS is ok with this due to a side effect of how I have to
> > keep a backing bitmap for each window. All I have to do is map from the
> > incoming window handle to the actual host bitmap and display some of
> > that. No problem except for the 'waste' of memory. If you want to get
> > the latest bits from inside ObjectMemory we will need a map from host
> > window handle to squeak bitmap oop. Easy way is to have an array held
> > by specialObjects that has the oops of the bitmaps used by all open host
> > windows. How else might one handle paint type OS events?
The way I'd do it is to completely ignore fullDisplayUpdate and friends.
Just send the paint events to Squeak and let *it* deal with it. The only
place where we move bits from here (Form) to there (Window) is in
#forceToScreen: - e.g., the sequence would look like:
* Drawing in Squeak
-> calls forceToScreen:
-> copies bits into Window
* Paint event in VM
-> generates paint event for Squeak
-> calls forceToScreen: to restore invalidated portion
Cheers,
- Andreas
|
|
From: Tim R. <ti...@su...> - 2004-09-10 01:00:34
|
In message <01af01c496b6$167fe030$b200a8c0@R22>
"Andreas Raab" <and...@gm...> wrote:
[snip]
> Correct. Unfortunately the current Canvas protocol is (how shall we say...)
> historically grown ;-) IOW, it doesn't really provide the neat high-level
> abstraction that we'd like to have.
So any chance of that being improved anytime (very) soon?
> > Probably WorldState should talk to its canvas instead of assuming Display.
>
> Likely yes.
I imagine making Form cope with force.... (doing nothing?) would let us
clean that up.
>
> > All canvases understand "forceToScreen: rect"; this should be used
> instead.
>
> Yes. It might also be interesting to check out Tweak's displayWorld
> implementation - here all of the Display related operations are routed
> through CWorldPlayer's display variable (and display really could be any
> kind of drawable surface such as a window).
Hmm, ok since Tweak is our current 'getting paid' target that is more
important.
>
> > > b) Which canvas to use? It looks like FormCanvas is the best candidate
> > > already in the system. We could subclass to make the assorted force...
>
> That's what I would do (and have done - see CTransformCanvas).
>
> > > messages go to our host window DisplayScreen analogues but then
> > > BalloonCanvas and other subclasses of FormCanvas would need sometinhg
> > > done. If I've understood it, we could consider changing FormCanvas to
> > > send all those force... messages to 'form' instead and then the 'form'
> > > could be an instance of HostWindow and we pass them on to the
> > > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but
> > > they all seem a bit ugly to me.
>
> This (the effect of wanting to use BalloonCanvas etc) is actually one of the
> reasons why a distinction of the responsibilities of drawing protocol
> (Canvas) vs. display surface (Window) can be advantageous.
Yes, I rather thought that was the intention but it is, shall we say a
litle muddied at the moment as you mention above. I was imagining a
litle cleanup of FormCanvas so that either a DisplayScreen or a
DisplayHostWindow (our current subclass of DisplayScreen that knows
it's host window handle in some abstract fashion) would work.
> By the end of the
> day, if you have a native window which has a form to display all you need is
> to vector forceToScreen: and getCanvas appropriately (not counting the
> various fixes in the rest of the system).
Never come across getCanvas before but it seems plausible. Not exactly
widely implemented in the standard system so it doesn't jump out as
important. And it seems a bit of a onetrick pony as well - nobody ever
gets anything other than a FormCanvas out of it! (normal 3.7 image)
[snip]
> > > windows. How else might one handle paint type OS events?
>
> The way I'd do it is to completely ignore fullDisplayUpdate and friends.
> Just send the paint events to Squeak and let *it* deal with it. The only
> place where we move bits from here (Form) to there (Window) is in
> #forceToScreen: - e.g., the sequence would look like:
> * Drawing in Squeak
> -> calls forceToScreen:
> -> copies bits into Window
> * Paint event in VM
> -> generates paint event for Squeak
> -> calls forceToScreen: to restore invalidated portion
Well this might work in many cases but I see some worries.
For example it isn't actually true that "The only place where we move
bits from here (Form) to there (Window) is in #forceToScreen:" since
that ain't how RISC OS does it. I have to (currently and I'd like to
change it) do the actual bit moving from Display to an OS pixmap at
ioShowDisplay time along with telling the OS that the area has been
dirtied. Then next time I get a paint event I blit the appropriate area
from the pixmap to the glass. Costs me a shadow copy of the Bitmap for
the Display (and any other windows we open) but makes it very cheap to
handle paints. Since can paints come at a furious rate in RISC OS (where
the active window can be anywhere in the stack of windows) this has
some value.
Which makes the second worry; the potential delay and disconnect
between the paint event and the redraw. Given the potential for
scheduling to delay the eventual forceToScreen it could be out of date
- say another window has been brought to front in the meantime. Does
the OS in question actually blit really straight to glass, or is there
some clipping area set when the paint event was sent? It may simply not
be a problem for those GUIs where the active window is at the top but I
suspect it could be a pain in some cases. Basically I'm wondering if
there is some context in the paint event that would need to be dealt
with. IIRC this was a real issue in older VW vms because of some
windows detail that got in the way. Hopefully it has all gone now.
I also have the practical problem that when I did have handling for
'draw right now dammit' things got very slow. As long as we can allow
the VM to handle paints if it wants to I can do something for now and
see about changes later.
I'm sure some people must think " why does he bother with this weird
OS" but it's good for everyone to have some heterogeneity around - it
keeps us honest about portability. And besides, oneday RISC OS will be
the predominant OS and all other feeble pretenders will have to kneel
in submission rant, rave.....
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
How was Thomas J. Watson buried? 9 edge down.
|
|
From: Andreas R. <and...@gm...> - 2004-09-10 21:38:25
|
Tim, > The obvious corollary is that if paint events only pass the damage > rectangle up to the image, then ioShowDisplay is called to move pixels > to the buffer and that is it. No actual displaying to glass. If I left > in the code to report the damage area I'd get a nice loop :-) So 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. Yup, but that isn't a problem. Not reporting paint events is equivalent to being the front-most window which is a very common situation. I wouldn't expect any trouble here. > John mentioned that OSX is double buffering the windows so it might be > an issue for him. And I hear the M$ is making big changes in their > graphics model for this avalon thingy; maybe they'll require apps to > report damage areas and only display pixels during a paint event handler > critical block? I'd be surprised to see this. But it wouldn't be hard to work around these restrictions in a way that uses the same model. > Well of course, but portability includes across time not just current > platforms. If M$/Apple does something dramatic in a future OS release > you'll be just as happy that we spent time on it as I want to be now - > probably more so because you (as in win32 vm) have millions of probably > screaming users whereas I only have a thousand or two to pacify. That's why I'm in favour of the simplest model possible ;-) Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2004-09-11 05:13:32
|
In message <020b01c4977e$497f27c0$6d5450d9@R22>
"Andreas Raab" <and...@gm...> wrote:
> Yup, but that isn't a problem. Not reporting paint events is equivalent to
> being the front-most window which is a very common situation. I wouldn't
> expect any trouble here.
Well I guess we'll see as we try it out. Let's just remember that for
certain OSs being active and not in front is pretty common.
The good news is that I have a plugin that let's me create a window
(though I don't quite seem to get the initial size I expect), display
into it and update it. It's amazing what fun you can have if you create
several windows and give them all the same id because you forgot to
increment the 'unique id' counter....
The bad news is it took me several hours longer than it should have
because I got persuaded to 'give the grass a quick mow'. It isn't
actually so quick to mow TWO F*^&*^ING ACRES of the stuff. Grr. And it
rained on me.
tim
PS two acres is about a hectare for those metric persons reading this.
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
"Wibble" said Pooh, the stress beginning to show.
|
|
From: Tim R. <ti...@su...> - 2004-09-14 04:19:51
|
In message <200...@bi...>
Ned Konz <ne...@bi...> wrote:
> > and FormCanvas>flushDisplay
> > which again talks to Display rather than the target form.
>
> And isn't called, and should be removed.
Easy :-) Even I can do that.
>
> > It's understandable that this might be done with only a single window,
> > though it seems a waste of time when the target form is not the Display.
>
> But forceDamageToScreen and flushDisplay are only used (should only be used,
> anyway) when it's clear that we're rendering to the Display.
If it's that important perhaps it would be better to have a subclass
(DisplayCanvas) that knows this. FormCanvas really ought to be what it
claims to be, a canvas for displaying upon a Form.
Whilst digging in to how remove Display dependency from FormCanvas
I find some oddness. One of the methods using Display is
FormCanvas>showAt: pt invalidRects: updateRects
| blt |
blt _ (BitBlt current toForm: Display)
sourceForm: form;
combinationRule: Form over.
updateRects do:
[:rect |
blt sourceRect: rect;
destOrigin: rect topLeft + pt;
copyBits]
and clearly this is a time wasting no-op when 'form' == Display. It
might possibly be a strange way of forcing out the damage rectangles
via BitBlts use of #showDisplayBits? It's obviously a touch more useful
when form ~= Display but if that is the case why would we want to blit
to Display anyway?
#showAt:invalidRects: is only really sent by
WorldState>displayWorld:submorphs: and then only if deferredUpateMode
is false.
That in turn depends upon #doDeferredUpdatingFor: which seems
like mostly work that could be done at some initialisation stage rather
than check every update cycle? In particular it uses
PasteUpMorph disableDeferredUpdates ifTrue: [^ false].
which appears to be a dead path these days. The only method that might
set this to false is PasteUpMorph class>disableDeferredUpdate: which is
a) tagged as old, Dan's, and from context possibly related to his
weathermachine hardware
b) commented in such as way as to define itself as redundant. To whit,
explaining that deferring is used by Morphic to do a sort of
double-buffering and that direct-write screens would use a different
canvas with a buffer. Thus no need for the classvar etc.... Maybe it's
so old it predates the full usage of the VM update flag?
Thinking of said flag, I spotted a number of comments that infer that
somebody assumed that it was a platform specific primitive, which it
isn't. #primitiveDeferDisplayUpdates has no conenction to any platform
setting or function. It _could_ have if that was really intended.
WorldState>doDeferredUpdatingFor: and
WiWPasteUpMorph>doDeferredUpdating are two such cases.
DisplayScreen>deferUpdates also comments
" If this underlying platform doesc not support deferred updates, this
primitive will fail"
which is silly since the prim always suceeds (unless the arg is
non-boolean) and deferred updates are always claimed to be supported;
another test in each of the doDeferred* mentioned before can be dropped.
If we could allow ourselves to update the prim to return the previous
value itself we could drop a silly method and a classvar in
DisplayScreen.
Later in doDeferredUpdatingFor: we have a tacky test for whether the
canvas is a FormCanvas on Display. If aWorld == World and the canvas is
not a FormCanvas etc, we set it to so be. Couldn't this be better done
in an init method? Likewise the later line for MVC stuff. This is
actually a problem if we want to use a FormCanvas with a form ~=
Display since it will get reset the first time we try updating it!
Should this sort of side-effecting be done here? We're getting way past
my knowledge of how all this convoluted spaghetti works.
So, deferredUpdateMode is almost certain to be true. If it is always
true, the 'canvas showAt:... could be dropped completely and the issue
of wastefully displaying Display on Display avoided completely rather
than just by accident.
Sheesh, all that for one method. On to the next one.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Programmer: One who is too lacking in people skills to be a software engineer.
|
|
From: Andreas R. <and...@gm...> - 2004-09-10 09:35:40
|
> > Correct. Unfortunately the current Canvas protocol is > > (how shall we say...) historically grown ;-) IOW, it > > doesn't really provide the neat high-level abstraction > > that we'd like to have. > > So any chance of that being improved anytime (very) soon? Soon yes. Very soon probably no. > > This (the effect of wanting to use BalloonCanvas etc) is > > actually one of the reasons why a distinction of the > > responsibilities of drawing protocol (Canvas) vs. display > > surface (Window) can be advantageous. > > Yes, I rather thought that was the intention but it is, shall we say a > litle muddied at the moment as you mention above. I was imagining a > litle cleanup of FormCanvas so that either a DisplayScreen or a > DisplayHostWindow (our current subclass of DisplayScreen that knows > it's host window handle in some abstract fashion) would work. Sounds like an excellent idea to me. > > The way I'd do it is to completely ignore fullDisplayUpdate and friends. > > Just send the paint events to Squeak and let *it* deal with it. The only > > place where we move bits from here (Form) to there (Window) is in > > #forceToScreen: - e.g., the sequence would look like: [...] > > Well this might work in many cases but I see some worries. > > For example it isn't actually true that "The only place where we > move bits from here (Form) to there (Window) is in #forceToScreen:" > since that ain't how RISC OS does it. Well, maybe not but forceToScreen: indeed calls (via primitiveShowDisplayRect via displayBitsOf) ioShowDisplay (which does move the bits) and my point is that this is the only place where this is required. > I have to (currently and I'd like to > change it) do the actual bit moving from Display to an OS pixmap at > ioShowDisplay time along with telling the OS that the area has been > dirtied. Sure - and that's precisely what forceToScreen: asks you to do ;-) > Which makes the second worry; the potential delay and disconnect > between the paint event and the redraw. Given the potential for > scheduling to delay the eventual forceToScreen it could be out of date > - say another window has been brought to front in the meantime. Does > the OS in question actually blit really straight to glass, or is there > some clipping area set when the paint event was sent? It may simply not > be a problem for those GUIs where the active window is at the top but I > suspect it could be a pain in some cases. Basically I'm wondering if > there is some context in the paint event that would need to be dealt > with. IIRC this was a real issue in older VW vms because of some > windows detail that got in the way. Hopefully it has all gone now. The portion of interest from the paint event is the invalidated region. Everything else is (AFAIK) irrelevant on pretty much any platform. While there are additional contexts that may be passed along one should be able to recreate them from the information we have (this is true of Windows for sure). > I also have the practical problem that when I did have handling for > 'draw right now dammit' things got very slow. As long as we can allow > the VM to handle paints if it wants to I can do something for now and > see about changes later. That's what we have forceDisplayUpdate for ;-) Some renaming might be in order but the Windows VM had done this for years and forceDisplayUpdate was introduced for the precise reason to force a synchcronous update of display. > I'm sure some people must think " why does he bother with this weird > OS" but it's good for everyone to have some heterogeneity around - it > keeps us honest about portability. And besides, oneday RISC OS will be > the predominant OS and all other feeble pretenders will have to kneel > in submission rant, rave..... Everything to keep you happy, Tim ;-) Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2004-09-10 17:31:08
|
> > > This (the effect of wanting to use BalloonCanvas etc) is > > > actually one of the reasons why a distinction of the > > > responsibilities of drawing protocol (Canvas) vs. display > > > surface (Window) can be advantageous. > > > > Yes, I rather thought that was the intention but it is, shall we say a > > litle muddied at the moment as you mention above. I was imagining a > > litle cleanup of FormCanvas so that either a DisplayScreen or a > > DisplayHostWindow (our current subclass of DisplayScreen that knows > > it's host window handle in some abstract fashion) would work. > > Sounds like an excellent idea to me. OK, I'll see if I can untangle enough to make a crack at it. > > > > The way I'd do it is to completely ignore fullDisplayUpdate and friends. > > > Just send the paint events to Squeak and let *it* deal with it. The only > > > place where we move bits from here (Form) to there (Window) is in > > > #forceToScreen: - e.g., the sequence would look like: > [...] > > > > Well this might work in many cases but I see some worries. > > > > For example it isn't actually true that "The only place where we > > move bits from here (Form) to there (Window) is in #forceToScreen:" > > since that ain't how RISC OS does it. > > Well, maybe not but forceToScreen: indeed calls (via > primitiveShowDisplayRect via displayBitsOf) ioShowDisplay (which does move > the bits) and my point is that this is the only place where this is > required. Ah - cross purposes here. On ROS ioShowDisplay doesn't put pixels to glass; it _does_ move them from Form to window-backing-pixmap, doing the endian/RGB->BGR transform on the way. Actual pixels to glass is done when a paint event is processed. ioShowDisplay tells the OS that a certain area has been dirtied and thus triggers the paint event at the next handleEvents opportunity. That's the split that was annoying me - ioShowDisplay gives us a handle to the Sq bitmap so it is possible to grab pixels directly and send them to glass if that is how your OS works. At paint-event time we don't have a convenient handle to the Sq bitmap _unless_ we make the assumption that it must be Display. Which is of course a bad assumption as soon as we have multiple windows. The obvious corollary is that if paint events only pass the damage rectangle up to the image, then ioShowDisplay is called to move pixels to the buffer and that is it. No actual displaying to glass. If I left in the code to report the damage area I'd get a nice loop :-) So 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. John mentioned that OSX is double buffering the windows so it might be an issue for him. And I hear the M$ is making big changes in their graphics model for this avalon thingy; maybe they'll require apps to report damage areas and only display pixels during a paint event handler critical block? [snip] > > The portion of interest from the paint event is the invalidated region. > Everything else is (AFAIK) irrelevant on pretty much any platform. While > there are additional contexts that may be passed along one should be able to > recreate them from the information we have (this is true of Windows for > sure). You've made my point for me. I hope there is no problem but I remember that there used to be and thus we need to remember the issue before charging off down a box canyon. That's all. > > I'm sure some people must think " why does he bother with this weird > > OS" but it's good for everyone to have some heterogeneity around - it > > keeps us honest about portability. And besides, oneday RISC OS will be > > the predominant OS and all other feeble pretenders will have to kneel > > in submission rant, rave..... > > Everything to keep you happy, Tim ;-) Well of course, but portability includes across time not just current platforms. If M$/Apple does something dramatic in a future OS release you'll be just as happy that we spent time on it as I want to be now - probably more so because you (as in win32 vm) have millions of probably screaming users whereas I only have a thousand or two to pacify. tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Strange OpCodes: XI: Execute Invalid op-code |
|
From: Ned K. <ne...@bi...> - 2004-09-10 21:51:35
|
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 |
|
From: Tim R. <ti...@su...> - 2004-09-11 05:18:27
|
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?
|
|
From: Ned K. <ne...@bi...> - 2004-09-11 05:49:20
|
On Friday 10 September 2004 10:17 pm, Tim Rowledge wrote: > > Remember too that we may be rendering to something that isn't making > > pixels. For instance, consider PDF output, or Postscript output, or the > > various OS-level (like Mac OS/X (or OS/2)) graphics APIs where you can > > cleanly render 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. Absolutely. It's just that we need to make the Canvases write-only. -- Ned Konz http://bike-nomad.com |
Thanks for helping keep SourceForge clean.
X