We are trying to improve the graphical (bitmap rendering) performance for the BeOS port. One issue we face lies in our current display model: squeak renders into its own bitmap, then we translate the squeak bitmap image into a BBitmap with the same pixel configuration as the display, then invalidated screen areas are drawn out of the BBitmap backing store. What is done on other platforms? Is the Squeak UI the same on all platforms? I.e., on any of the supported platforms, does squeak use "native" windows for its windows, or do all platforms render into a window like is currently done on the BeOS?
thanks, --dick peskin
================================= R. L. Peskin, Rutgers Univ. ; peskin@caip.rutgers.edu; http://www.caip.rutgers.edu/~peskin VT Phone (802) 824-4558 NJ Phone (732) 445-4208 "The corporate culture is concerned less with Occam's razor than his aftershave lotion."
I.e., on any of the supported platforms, does squeak use "native" windows for its windows, or do all platforms render into a window like is currently done on the BeOS?
I think that most platforms do it the same way (I can't really speak for *all* platforms) that is, copy the Squeak Display object into the hosts Squeak window. There are slight differences in the way the different ports deal with byte reversal (e.g., on Win32 this is done inplace, once before copying the Display object into the window and once after this has been done) or whether a host bitmap is needed for Display. But besides that your exactly on the right trail.
Andreas
At 7:57 PM +0100 12/24/98, Andreas Raab wrote:
I think that most platforms do it the same way (I can't really speak for *all* platforms) that is, copy the Squeak Display object into the hosts Squeak window. There are slight differences in the way the different ports deal with byte reversal (e.g., on Win32 this is done inplace, once before copying the Display object into the window and once after this has been done) or whether a host bitmap is needed for Display. But besides that your exactly on the right trail.
Thanks Andreas-- Where do I find this specialized code? I have looked over the sqMacWindows.c and the only thing I see (other than window creation and event handling) is ioShowDisplay() which appears to do a PixMap to BitMap conversion, followed by a CopyBits(). Should I be looking elsewhere as well?
How does interp.c call for the display? Is "ioShowDisplay()" called from the interpreter or is there another function named used by the interpreter?
Our problem is very slow drawing, which was unexpected for the BeOS. We don't want to change the automatically generated interp.c, so we need to fix this in one of the machine specific calls. --dick peskin
================================= R. L. Peskin, Rutgers Univ. ; peskin@caip.rutgers.edu; http://www.caip.rutgers.edu/~peskin VT Phone (802) 824-4558 NJ Phone (732) 445-4208 "The corporate culture is concerned less with Occam's razor than his aftershave lotion."
On Thu 24 Dec, Richard L. Peskin wrote:
Where do I find this specialized code? I have looked over the sqMacWindows.c and the only thing I see (other than window creation and event handling) is ioShowDisplay() which appears to do a PixMap to BitMap conversion, followed by a CopyBits(). Should I be looking elsewhere as well?
Yes - the Mac does just what you describe and needs no more since the BitBlt code in Squeak was written for the Mac. The Mac is almost the only mainstream machine that is bigendian, so all the other systems have to some conversion in the process of ioShowDisplay(). Look in sqWin32Windows.c, sqX11Windows.c, sqRPCWindows.c (get them from Andreas', Ian's or my websites) to see examples of how to handle it under different circumstances. RPC & W32 have to reverse the Display bitmap, call some OS stuff to transfer it ot the screen and then de-reverse it back to 'normal'. X11 has to do a whole bundle of stuff, and Ian managed to avoid doing the reverse in place & de-reverse. Sounds Like BeOS will have to use one or other of these tricks.
Of course, there is/was my little-endian BitBLT system that avoided all this, but since nobody wanted to use it, I've stopped supporting it.
How does interp.c call for the display? Is "ioShowDisplay()" called from the interpreter or is there another function named used by the interpreter?
ioShowDisplay is it. Your ioShowDisplay routine uses the global variables and passed in parameters to do whatever is needed.
Our problem is very slow drawing, which was unexpected for the BeOS. We don't want to change the automatically generated interp.c, so we need to fix this in one of the machine specific calls.
Don't forget that it is entirely possible that the 'copy a big bitmap from here to there on the screen' might not be as well optimised as other parts of the system. It is often the case that trying to do anything not-quite-normal in an OS is fraught with problems - since 'proper' applications for that OS don't do anything that exercise those areas.
It used to be a joke at ParcPlace that VisualWorks ought to be sold to OS companies as a test suite....
tim
Our problem is very slow drawing, which was unexpected for the BeOS. We don't want to change the automatically generated interp.c, so we need to fix this in one of the machine specific calls.
Don't forget that it is entirely possible that the 'copy a big bitmap from here to there on the screen' might not be as well optimised as other parts of the system.
But on most systems, displaying bitmaps is a crucial part of the graphics interface and usually pretty fast. You might check out different host display depths in combination with different Squeak display depths since a bad combination may dramatically affect performance (try using Squeak's 16bit display depth with a 6-5-5 or 5-6-5 host depth ;-)
Andreas
squeak-dev@lists.squeakfoundation.org