RE: Win32Window how to get Squeak's window Handle? VM?

---

> From: [hidden email]

---

PC Magazine’s 2007 editors’ choice for best web mail—award-winning Windows Live Hotmail. Check it out!

Jason,

My experience is that home-grown widgets can indeed outperform the
native variety under some situations.  I would argue that it is not so
much that bitblt is fast (the native guys have access to it too), but
that when emulating, one can bypass some algorithmic inefficiencies in
message-driven GUIs.  IMHO, emulation is most likely to be of benefit
when building a composite widget with a large number of sub-widgets.
Doing it all with native widgets means that each sub-widget gets its own
message queue, and one must shoe-horn interactions into it.  When
emulating, only the top-level widget needs an OS-level queue, and the
hordes of sub-widgets are accessible directly vs. by individual queues
and their associated context switches.

That is not to say that native widgets are bad, only that one can have
too much of a good thing.  I would very much like to see Squeak grow the
ability to use them.  On one level, I like Squeak's single main window,
but it does interfere with some types of work that I do on Windows with
Dolphin.  Perhaps the ideal thing would be to have an option not to use
it, and there have been efforts in that direction (I do not recall the
details or status).

Squeak's need for native widgets is greatest in terms of the feel of the
GUI.  Halos and "the hand" are great prototyping/editing concepts, but
they are no substitute for a consistent presentation.  Not everything in
modern GUIs is bad<g>.  I am not alone in looking for ways to break
dependencies on Microsoft, and I think Squeak could benefit from
substantial projects seeking a new home.

For those who say "don't break our toy," I note that one can still do
all kinds of incredible bleeding-edge stuff on top of a clean
foundation.  I urge you to stop thinking of Squeak as a toy, and start
thinking of how to make a tool that can build toys (a worthy goal) as
well as boring stuff has market and research value.

Bill




======================
J J <azreal1977@...> wrote:

This message sounds like Ffenestri is the planned future GUI interface
of Squeak.  Is that so, or I read it wrong?  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.

Note, I'm not expressing an opinion here, just trying to understand.

Thanks,
Jason

Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

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. 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.

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.

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
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Moves his lips to pretend he's reading.

On 22/07/07, tim Rowledge <[hidden email]> wrote:
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
screen.

> 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.

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
gone.
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.


--
Best regards,
Igor Stasenko AKA sig.