Morphic graphics, Displaying fonts & canvases

sig siguctua at gmail.com
Fri Apr 20 20:15:15 UTC 2007


> In answer to sig's point about Ffenestri still being bitblt focussed
> - well, yes I guess it is but that is because the system as a whole
> is blit centred. Nothing prevents you from using the Ffenestri calls
> to open and manipulate windows without copying a bitmaps to them. If
> yo uwant to add a way to get some OS identifier for the window to
> pass to Cairo/openGL/whatever then feel free. It's open source, after
> all. Don't forget the Cairo interface plugin/classes either; a lot of
> work has been done but much remains. You might make much faster
> progress by building on what is already there.
>
Wow.. a ton of work being done. I didn't forgot, i just didn't knew ;)
In a RomePlugin i see that most primitives doing all hard work on VM
level, where all plugins do.
I dont think that this is the way of doing things. My choice is FFI
calls since OpenGL is present by default on most modern platforms.
This gives me much control and freedom on what i can and what i can't
do in squeak, without writing extra code / installing additional
plugins with tons of functions.
I dont know how its easy to develop and debug plugins for squeak but i
think its harder than just run smalltalk code. I wrote a small plugin
fith a few functions which just enable OpenGL  context for main
window, and from my experience writing something more than that will
require huge amount of time and it then hard to maintain and expand.

And since any drawing using hardware acceleration leads to calls to
OpenGL/DirectX/(your favorite) stuff anyways i see no point why i
should not use them directly from squeak.

I have long expereince writing programs on C/C++ and came to squeak
because i need something better than that. But writing plugins which
require more than a few lines of code is the way of returning back to
C. why do we need squeak at all then?



More information about the Squeak-dev mailing list