Menu
▾
▴
squeak-vmdev
|
From: Tim R. <ti...@su...> - 2004-03-21 02:51:47
|
Whilst playing with all this VM code I noticed a bit of confusion in the area of fullDisplay and it's cousins. Strange Mac code - sqMacUIEvents>case: updateEvt -> fullDisplayUpdate -> ioForceDisplayUpdate -> does nothing. Comment claims to use ioShowDisplay... Similar kind of oddity in comments in win32 - sqWin32window>ioForceDisplayUpdate claims:- /* force an update of the squeak window if using deferred updates */ but appears to NOT update if defer is on. Oh and comment in case: WM_PAINT claims fullDisplayUpdate will call ioShowDisplay too. In fact there seems to be a little confusion as to which code forces a display update right now, which can be deferred by the image and which can be done lazily by the vm. I'd be interested to know what the design intent is here! Who knows, it might enable me to further improve the RISC OS performance. primitiveBeDisplay comment claims that the Display oop will be recorded in the specialOopArray as well as a separate variable. Currently there appears to be no such variable. Shall we change the comment or the code? A loooong time ago I wanted to have that separate variable but nobody else liked the idea and I reworked stuff to not need it. Does anyone want it? tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Nostalgia: The good old days multiplied by a bad memory... |
|
From: Ian P. <ian...@in...> - 2004-03-21 03:07:35
|
On 21 Mar 2004, at 03:52, Tim Rowledge wrote: > In fact there seems to be a little confusion as to which code forces a > display > update right now, which can be deferred by the image and which can be > done lazily by the vm. I'd be interested to know what the design intent > is here! fullDisplayUpdate() calls ioShowDisplay() for the entire Display (or whatever surface, yada yada) area. ioShowDisplay() tells the VM that the Display has changed (and where). (E.g., the Unix/X11 code grabs a PixMap out of the Display object and paints it into the X11 window, but network/server latencies don't guarantee an immediate effect on the physical screen. Other VMs might just add the rectangle to a damage list, in preparation for...) ioForceDisplayUpdate() tells the VM that any screen updates from previous calls to ioShowDisplay that have not as yet been forced into the physical framebuffer should now be forced into the framebuffer. (E.g., the Unix/X11 code calls XFlush() which returns after the server tells us that all pending PixMap writes have been propagated to the framebuffer -- which is kind of pedantic, but it does allow the image to assume the user is now seeing the most recent Display contents at the time the prim returns. Other VMs might defer synchronising the physical screen with the Display explicitly -- e.g., if they blit bits directly out of the Display object and use ioShowDisplay() only to maintain a damage list to avoid repaints of overlapping areas.) Any clearer yet? Ian |
|
From: Tim R. <ti...@su...> - 2004-03-21 04:58:30
|
In message <ED1...@in...>
Ian Piumarta <ian...@in...> wrote:
> fullDisplayUpdate() calls ioShowDisplay() for the entire Display (or
> whatever surface, yada yada) area.
That one is pretty reasonable though the commenting could be more
helpful as to the actual users. It doesn't refer to deferDisplayUpdates
within any of the slang code.
>
> ioShowDisplay() tells the VM that the Display has changed (and where).
> (E.g., the Unix/X11 code grabs a PixMap out of the Display object and
> paints it into the X11 window, but network/server latencies don't
> guarantee an immediate effect on the physical screen. Other VMs might
> just add the rectangle to a damage list, in preparation for...)
Indeed, but what interaction should it have with the deferDisplayUpdates
flag? I'm puzzled by the way that the win32 code for this does involve
deferDisplayUpdates. I suppose my concern is that if the inner vm code
has some subtle difference to other platforms we could see odd effects
since a great deal of graphics code is written by Andreas on windows.
For example, for several releases some time ago I didn't see any morphs
while they were being dragged because nobody had mentioned some change
or other involving force update and defer and blahblah. Don't recall
the details anymore but it was that general area.
>
> ioForceDisplayUpdate() tells the VM that any screen updates from
> previous calls to ioShowDisplay that have not as yet been forced into
> the physical framebuffer should now be forced into the framebuffer.
> (E.g., the Unix/X11 code calls XFlush() which returns after the server
> tells us that all pending PixMap writes have been propagated to the
> framebuffer -- which is kind of pedantic, but it does allow the image
> to assume the user is now seeing the most recent Display contents at
> the time the prim returns. Other VMs might defer synchronising the
> physical screen with the Display explicitly -- e.g., if they blit bits
> directly out of the Display object and use ioShowDisplay() only to
> maintain a damage list to avoid repaints of overlapping areas.)
That's fine; it would be nice to have better commenting of this where
possible. Again, the win32 code refers to deferDisplayUpdates which has
the same concern as above. Which code should take note of deferment and
which can or should ignore it (I guess any of it can ignore it at a
potential performance cost).
>
> Any clearer yet?
Somewhat but it would be nice to get it documented more cleanly. Some
explanation of the pixel reversal when depth is -ve would be good to get
in as well.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: SFA: Seek Financial Assistance
|
|
From: Andreas R. <and...@gm...> - 2004-03-21 12:18:06
|
Tim, > Indeed, but what interaction should it have with the > deferDisplayUpdates flag? I'm puzzled by the way that > the win32 code for this does involve deferDisplayUpdates. ioForceDisplayUpdate is a no-op on Windows these days. Ignore it. > That's fine; it would be nice to have better commenting of > this where possible. Again, the win32 code refers to > deferDisplayUpdates which has the same concern as above. And the same answer. Note that both of these depend on the setting of the "fDeferredUpdate" variable which predates "deferDisplayUpdates" a couple of years. But it's turned off by default these days. Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2004-03-29 00:13:26
|
It's 3.7 beta time and thus time to make another release ofVMMaker. Since I've made a bunch of changes I thought I'd mention some of the details and ask if they cause any problems for people. The b1 version added to 3.6:- Add ClassRefsBrowsingForPlugins ( extends image support for classrefs) Add InterpreterSimulator-primitiveGetAttribute (support Simulator) Add InterpreterSimulator-sqGrowMemoryBy (ditto) Add primYield.1.cs - adds primitive for ProcessorScheduler>yield Add primCopy.1.cs - adds a prim to copy Objects, revised from ar original to make numbered (168) Add SlightlyFasterActivate-JMM.8.cs Add ImageStartupFix-JMM.1.cs - consider doing the object counting for real? Add bytecodePrimPoint-internal-tpr.1.cs - variant of MakePrimPointXInternal-JMM.1.cs Add InterpreterPlugin-halt.st Add isArray stuff - update Cross/vm/sqVirtualMachine.[ch] - IsArrayVM.1.cs - which changes core VM code to use isArray: - IsArrayVMProxy.1.cs- which add isArray to the proxy for simulation - IsArrayPlugins.2.cs - which uses isArray in some plugin code This version adds:- fixes for the object-as-methods prims New mechanism for requiring the CCodeGen to retain methods even if they appear unused. This spreads the responsibility around to class methods named #requiredMethodNames, called as part of CCodeGenerator>addClass: New primitive calling; instead of a case statement we have a table of function pointers and jump directly. To support this a macro and typedef are added to Cross/sq.h The cumbersome timing of primitives is removed from primitiveResponse since most internal numbered prims are quick. Those that are not use #forceInterruptCheck to require an ASAP checkForInterrupts. fIC is essentially idempotent and can be called several times in a prim without harm. I use this instead of simply setting the interruptCheckCounter to 0 because that seems to mess up the feedback mechanism. The external call prim now has the primitive timing code since many named prims are quite long operations; I'm still looking for a nice way to improve that. Maybe changing the codegen to do something clever. I guess the ffi prim ought to do something similar. Note that this change could be backed out if the latter two points cause a problem for anyone. Allowing plugin code to call forceInterruptCheck requires a step in sqVirtualMachine - but then Andreas' isArray code had already caused that. Internal code like ioGetNextEvent(), ioShowDisplay() etc that takes a long time can freely call fIC if it seems warranted. The evidence so far is that the timer change is very worthwhile on RISC OS and mildly beneficial on other platforms. It also allows the more direct usage of function pointers in the prim table which will have other uses later. :-) Misc. commenting, reformatting and tidying. tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Strange OpCodes: SSD: Scramble Segment Directory |
Thanks for helping keep SourceForge clean.
X