Win32Window how to get Squeak's window Handle? VM?
siguctua at gmail.com
Mon Jul 23 10:25:14 UTC 2007
On 22/07/07, tim Rowledge <tim at rowledge.org> wrote:
> On 22-Jul-07, at 22-Jul;12:11 AM, J J wrote:
> > This message sounds like Ffenestri is the planned future GUI
> > interface of Squeak. Is that so, or I read it wrong?
> I would love to see Ffenestri be used as part of a new, better, UI
> framework. Whether it is or not is up to whoever has the drive, time,
> skill, opportunity and determination to make it.
> > I was under the impression that the BltBlt method was faster then
> > using native windows (though it could be that just the wxWidget
> > libraries are themselves slow). Is this true? Sig has mentioned
> > he can get a 3 to 5 times speed up from BltBlt using OpenGL.
> Depends on so many things it's not possible to make a simple answer.
> BitBLT within object memory is almost certainly faster than any usage
> of an external library that tries to do the same thing simply because
> there is typically a large impedence mismatch that takes time to
> correct - OOPs have to be converted to weird handles and passed to
> library calls that expect bitmaps to be in middle-endian upside-down
> backwards edge-twisted form and then it all has to be copied out of
> object memory to the l;ibrary buffer and ... then is all has to be
> reversed at the end.
Same is true for bitblt - when hardware display memory layout is not
same as used with bitblt, then you need to convert form bits to
hardware specific format to be able to draw them correctly on the
> On the other hand, if you can do all your
> drawing by making library calls to draw an anti-aliased 3.14 pixel
> thick line with complex dash pattern onto an OS drawing surface held
> in the memory of a staggeringly fast GPU - well then you're really
> cooking with gas.
Yes, indeed, OpenGL provides a basic api for drawing simple
primitives, such as lines/triangles. And gives you much control on how
to render them without caring about what pixels you need to modify in
form buffer to draw your line(s).
For instance, when i coded an ellipse/arc drawing using GL calls, all
i was need is to calculate point positions on arc. Everything else is
just not my concern.
> The nice thing about using bitblt for everything is that it is
> superbly portable; all you need to do for any platform is to find out
> how to get that chunk of memory called 'Display' to where it will
> appear on the right bit of glass. In some cases where you happen to
> be the builder of the machine this can be as simple as setting a
> couple of hardware registers to point to the right place in object
> memory. In other cases it can be so convoluted that the writer
> deserves a CS PhD simply for the ability to claim straight facedly
> that it should work - see the RISC OS display stuff or even the X
> display stuff.
You are right about portability, but nowadays its hard to find a PC
where graphics memory not backed with GPU which can be used for making
fast blitting operations or rendering 3D.
Even modern cell phones having chips which supporting OpenGL ES :)
And i think that days, when graphics devices/cards was just a region
of memory to which you can write bits to show something on display is
I'm not saying about other devices (like plotter or vector display),
where concept of 'pixel' was never exists, and thus, using blitting
for them is not possible, while rendering using a primitive commands
(like line/circle) is supported well.
> On the other hand, driving the 'real' OS api, or going via some
> tolerably competent library such as Cairo, has many advantages in
> performance and inherited capability at the cost of restricting
> portability to those platforms where the library works.
> The really nice thing about a good system like Smalltalk is that
> there is nothing technical stopping us having the high-level code not
> care which low-level drawing mechanism is in use. On a cairo-less
> direct buffer machine (hi Jecel!) we might lose the anti-aliased
> shimmering beauty of Vista Aero (blech) but simple clean lines can
> still do the job. Unless someone chose to implement all the same
> glitz internally of course. Or even port Cairo/whatever. If we get
> around to doing any of place, please let's not make the mistake of
> copying the retarded crap laughingly called 'modern user interface', eh?
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Moves his lips to pretend he's reading.
Igor Stasenko AKA sig.
More information about the Squeak-dev