Ok, well this would be in the squeak V5 macintosh cocoa VM. In general the smalltalk code alters bits in the special object TheDisplay
At some point the Smalltalk code calls primitiveShowDisplayRect or primitiveForceDisplayUpdate to move the bits from TheDisplay Oops to the host supporting platform's UI. This invokes the platform code ioShowDisplay(), *some* platforms who are multiple window aware may turn that into ioShowDisplayOnWindow() Now the intent of the logic is that the bits, rectangle of interest and target rectangle in the host platform display are given to the platform for visual display, and in theory the smalltalk side should issue a ioForceDisplayUpdate to sync a "Frame" from time to time this has then intent of *buffering* data between frame updates. To complicate things the Frame Sync might not happen so you always have to think about flushing data. Also the platform may transform the data from one color depth and color ordering to another to mediate between what the Squeak image thinks it is using versus what the hardware supports. I think the Unix side always flushes every byte accepted by the ioShowDisplayOnWindow immediately, this ensures you have no dangling flushes, but means there is no buffering of display writes between ioForceDisplayUpdate The older carbon macintosh VM writes every byte to the carbon window backing store (very fast), but on every X milliseconds flushes to the os-x display manager (very slow), or every Y milliseconds as it checks for dangling drawing as a result of a missing ioForceDisplayUpdate. The newer cocoa V5 VM Is modelled on the iPhone logic and uses 16 animation layers. On a ioShowDisplayOnWindow we record what rectangles are dirty. When the ioForceDisplayUpdate happens either by the Smalltalk code or forced as a timer pop we copy the data from TheDisplay based on the dirty rectangles, create a CGImageRef and update the animation layer tile. That triggers the GPU to do the right thing. Based on an Apple Engineering ticket I opened the methodology here is the fastest way to get bitmapped data to the iPhone display, and benchmarking shows the same solution gives better performance on os-x than the older obsolete carbon code. It *might* be possible to get better performance using OpenGL, but benchmarking on the iPhone shows the time taken in ioShowDisplay is near zero so it's hard to justify the work, as an example the frame rate of Scratch was tied up in the Scratch drawing logic, not the platform logic under ioShowDisplay. On 2010-05-13, at 3:14 AM, Henrik Sperre Johansen wrote: > On 12.05.2010 20:13, Andrei Stebakov wrote: >> That's right, looks like it sends full-blown images (not the delta, not the >> commands to x-server) and re-drawing takes forever. I wonder if it's a Pharo >> issue or x-server's? My xterm works pretty fast compared to Pharo though... > AFAIK, this is a consequence of the rendering method used in Squeak/Pharo > image/VM's. > If I've understood the Mac platform-rendering code correctly, the way it > works, is that a special Display bitmap is kept accessible to both image and > VM. > When rendering image side, all draws end up on the Display bitmap. (Using > bitBlt as a context, rather than using f.ex. a HostGraphicsContexts to draw > using the equivalent x-server/quartz/directDraw commands) > > Then, when it comes time to actually display, the VM takes the registered > damage rects, and sends the contents of the Display bitmap in those areas for > display. > (In the Mac VM, this is actually folded down to one of 16 regions which are > marked dirty or not, not sure how it works on other platforms). > So yes, full-blown images is ever only sent. > > The advantages I can see is that: > 1. All rendering logic is actually written in smalltalk. (Well, as part of > the platform-independent, compiled-to-C VM sources at least) > 2. It will render exactly the same on all platforms, due to #1. > 3. The platform support code for rendering is really simple, all you need is > the ability to display bitmap regions to the screen. > > Cheers, > Henry. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
