It's one more, isn't it?
So now I have no choice but to buy a new Mac (maybe that 17in
Powerbook), cuz I got that Spinal Tap reference from their page
announcing X11 (via XFree86) for the Mac, seamlessly integrated with
Darwin, sitting atop Quartz for maximum performance.
http://www.apple.com/macosx/x11/
This is big because Cello, the universal CL gui you all will be using
soon, might be using FreeGlut for its window manager, and FG has been
ported only to win32 and X11. I was a little bummed that I was going to
have to do the Quartz port myself, looks like I am off the hook.
And just yesterday I discovered another promising tidbit: turns out
/all/ graphics on OS X are produced via (wait for it) OpenGL! I had been
wondering if that design choice (for Cello, the universal CL gui you all
will be using soon) would hold up. Guess I can relax. :)
Something else deeply cool happened ysterday while hacking the
OpenGL-ification of Cello. Slowly coming up to speed on the ogl
coordinate geometry, I finally noticed that it is a natural for the
Cello scheme. Ripped out a whole wadge of code which made up for the
absence of gl-translatef. And the "layers" mechanism by which one can
build up the appearance of something with a list of primitives
(background color, frame, bitmap) will be natural fit with the ogl
display-list optimization.
Can't celebrate yet 'cuz I still have a couple of FreeGlut proofs of
concept to execute, but so far so eleven.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
...
> This is big because Cello, the universal CL gui you all will be using
> soon, might be using FreeGlut for its window manager, and FG has been
*cough*
> ported only to win32 and X11. I was a little bummed that I was going
> to have to do the Quartz port myself, looks like I am off the hook.
>
> And just yesterday I discovered another promising tidbit: turns out
> /all/ graphics on OS X are produced via (wait for it) OpenGL! I had
> been wondering if that design choice (for Cello, the universal CL gui
> you all will be using soon) would hold up. Guess I can relax. :)
While using OpenGL for everything is a fine design choice, it's
certainly not true that all graphics in OS X is produced via OpenGL.
The "window manager" will use OpenGL texture support to accelerate
top level window operations like moving and compositing
semi-transparent windows; this is "Quartz Extreme" and is supported on
video cards with enough video memory.
Tim
Timothy Moore wrote:
>
> While using OpenGL for everything is a fine design choice,
OK.
>... it's
> certainly not true that all graphics in OS X is produced via OpenGL.
Did I misinterpret?:
http://www.infoworld.com/articles/pl/xml/02/12/16/021216plpowerbook.xml
" The ATI Radeon 9000 display controller with 64MB of RAM makes a big
difference in perceived speed. Apple uses hardware-accelerated OpenGL
(comparable to Microsoft's DirectX gaming graphics technology) for the
entire OS X GUI. Where ClearType font smoothing slows Windows way down,
Apple's smoothed text draws fast and scrolls quickly. The combination of
the ATI graphics chip and the 1GHz PowerPC processor keeps the interface
responsive, even in low-power mode. "
I was especially stoked that stroke fonts come out decent under OpenGL.
I had been concerned by the appearance of outline fonts as produced by
ogl after getting display lists from wglUseFontOutlines. I know fonts
under win32 get optimized for the resolution at which they will appear.
I was hoping that the stuff I was seeing was suboptimal only because I
was bypassing the optimization (and could eventually recover that by
hook or by crook).
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Timothy Moore wrote:
> >... it's
> > certainly not true that all graphics in OS X is produced via OpenGL.
>
> Did I misinterpret?:
>
> http://www.infoworld.com/articles/pl/xml/02/12/16/021216plpowerbook.xml
>
> " The ATI Radeon 9000 display controller with 64MB of RAM makes a big
> difference in perceived speed. Apple uses hardware-accelerated OpenGL
> (comparable to Microsoft's DirectX gaming graphics technology) for the
> entire OS X GUI. Where ClearType font smoothing slows Windows way
> down, Apple's smoothed text draws fast and scrolls quickly. The
> combination of the ATI graphics chip and the 1GHz PowerPC processor
> keeps the interface responsive, even in low-power mode. "
You didn't misinterpret, but the article's comment about the "entire
OS X GUI" is simplistic at best and simply wrong at worst. The OS X
graphics library, Quartz, renders into off-screen bitmaps and then
blits the results to the screen all at once. Quartz does not use
OpenGL.
In OS X 10.2 (Jaguar), on platforms with the appropriate video cards,
the Quartz Extreme optimizations will be enabled. Quartz Extreme
manages all the windows on the screen as OpenGL textures. It uses
OpenGL rendering, compositing, and texture update operations to
accelerate the Quartz blit step and window manager functions like
moving windows around the screen.
On platforms that support Quartz Extreme I suppose you could say that
"OpenGL is used for the GUI," but not in the way you expect. OpenGL
is used after the window contents are rendered using Quartz.
Disclaimer: This is all AIUI.
Tim
Timothy Moore <·····@bricoworks.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Timothy Moore wrote:
> > >... it's
> > > certainly not true that all graphics in OS X is produced via OpenGL.
> >
> > Did I misinterpret?:
> >
> > http://www.infoworld.com/articles/pl/xml/02/12/16/021216plpowerbook.xml
> >
> > " The ATI Radeon 9000 display controller with 64MB of RAM makes a big
> > difference in perceived speed. Apple uses hardware-accelerated OpenGL
> > (comparable to Microsoft's DirectX gaming graphics technology) for the
> > entire OS X GUI. Where ClearType font smoothing slows Windows way
> > down, Apple's smoothed text draws fast and scrolls quickly. The
> > combination of the ATI graphics chip and the 1GHz PowerPC processor
> > keeps the interface responsive, even in low-power mode. "
>
> You didn't misinterpret, but the article's comment about the "entire
> OS X GUI" is simplistic at best and simply wrong at worst. The OS X
> graphics library, Quartz, renders into off-screen bitmaps and then
> blits the results to the screen all at once. Quartz does not use
> OpenGL.
>
> In OS X 10.2 (Jaguar), on platforms with the appropriate video cards,
> the Quartz Extreme optimizations will be enabled. Quartz Extreme
> manages all the windows on the screen as OpenGL textures. It uses
> OpenGL rendering, compositing, and texture update operations to
> accelerate the Quartz blit step and window manager functions like
> moving windows around the screen.
>
> On platforms that support Quartz Extreme I suppose you could say
> that "OpenGL is used for the GUI," but not in the way you expect.
> OpenGL is used after the window contents are rendered using Quartz.
>
> Disclaimer: This is all AIUI.
Further, I believe that Quartz is built on top of display-PDF. See [1]
and mouse over the Quartz button to see a few more details. For even
more details see [2]. At any rate, if you you believe the PR, they're
doing a fair bit of fancy graphics work in their Quartz 2D engine and
then, as Tim says, using OpenGL to blit it up on the screen. And in
the other direction, I think if your app wants to do fancy 3D graphics
with OpenGL, the Quartz Compositor, which provides windowing services,
can mix them in "seemlessly" (according to the PR verbiage) the same
way it can mix in Quicktime.
-Peter
[1] <http://developer.apple.com/macosx/architecture/index.html>
[2] <http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/SystemOverview.pdf>
--
Peter Seibel
·····@javamonkey.com
Peter Seibel wrote:
> Further, I believe that Quartz is built on top of display-PDF.
That I knew, and I thought they had mapped PDF to OpenGL when I read the
InfoWorld bit.
> they're
> doing a fair bit of fancy graphics work in their Quartz 2D engine and
> then, as Tim says, using OpenGL to blit it up on the screen.
Didn't realize the blit was that expensive.
But then that InfoWorld article must be mistaken, because it implied the
font-smoothing was being accelerated by hardware support for OGL, while
youse guys seem to be saying the CPU(s) are still burdened with that.
Oh well, ogl seems to be working nicely for Cello -- just about my last
worry fell by the wayside yesterday and ogl is starting to make more
sense, so things should accelerate nicely now.
Got confirmation from the FreeGlut maintainers that with X11 on the Mac
the port to OS X should Just Work(tm). Then the only problem is getting
Lisp implementations which cannot be called from C working.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> Didn't realize the blit was that expensive.
What's expensive is doing the alpha compositing. Remember, all
background windows' title bars are transparent in Mac OS X. In
addition, some applications, (such as Terminal.app) allow the user to
create transparent windows. This means that, for example, I can be
watching a QuickTime movie through a terminal window which is paging a
unix man page, or running top, etc.
With Quartz Extreme, each application is only responsible for
computing and updating the contents of it's windows. It then hands
these to the window manager, which treats each window's contents as an
OpenGL texture, and then uses the OpenGL accelerated graphics card to
composite all of these transparent (and opaque) layers, which offloads
a fair bit of work to the GPU which would otherwise have to be done by
the CPU.
A common test is to create a transparent terminal window running top,
with a quicktime movie looping behind it. Now jiggle the terminal
window. This requires the window manager to update the transparency
composites many times a second. Without Quartz Extreme, the QuickTime
movie will drop frames (i.e., skip) or the sound will get choppy, or
both. On slow machines it will simply grind to a halt. With a graphics
card capable of doing Quartz Extreme, the movie runs smoothly.
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > Further, I believe that Quartz is built on top of display-PDF.
>
>
> That I knew, and I thought they had mapped PDF to OpenGL when I read
> the InfoWorld bit.
>
>
> > they're doing a fair bit of fancy graphics work in their Quartz 2D
> > engine and then, as Tim says, using OpenGL to blit it up on the
> > screen.
>
>
> Didn't realize the blit was that expensive.
Well, don't take my word for that bit. I was just repeating what Tim
said there. But if you follow the links I posted, with your more
extensive knowledge (i.e. > 0) of what OpenGL provides, you might be
able to read between the lines better than I was able.
> Oh well, ogl seems to be working nicely for Cello -- just about my
> last worry fell by the wayside yesterday and ogl is starting to make
> more sense, so things should accelerate nicely now.
Right on. When do we get to see some code. ;-)
-Peter
--
Peter Seibel
·····@javamonkey.com
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>Oh well, ogl seems to be working nicely for Cello -- just about my
>>last worry fell by the wayside yesterday and ogl is starting to make
>>more sense, so things should accelerate nicely now.
>
>
> Right on. When do we get to see some code. ;-)
I'll try to have a demo for ILUG-NY meeting after next.
I just have push buttons, static text, arbitrary installed fonts, bitmap
or outline, check boxes and radio groups/buttons working. Next come the
fearsome scroll bars, list boxes, tab controls, sliders, textedit
(including multi-line wrapped text). Glut does menus, so I guess I can
milk those. picture buttons, pictures in general, should be cake for
ogl. any requests?
Still have to learn/do display lists and vertex arrays, two ogl
optimizations. And it turns out I cloned the bindings from non-free
headers, which makes it derived which means I gotta start over from free
headers. no big.
Still some issues carrying on after a backtrace, even had to bounce the
IDE today. I think that can all get polished.
One cool thing back in Cellville was that the long bit-rotted "drifter"
cell type got resurrected to support starting/stopping a spinning
tetrahedron.
Working on ACL/Win32. First ports would be LW and Corman, then MCL/X11.
Not sure what to do about CMUCL not being callable from C. Might defer
that since I have been told no CMUCLer will have any interest in Cello
anyway. :)
massive amounts of code cleanup possible, so first release might be to
friendlies who will provide feedback and help determine what doc to
crete. and the camelcase isStillRampant, so...<g>
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton wrote:
>
> Not sure what to do about CMUCL not being callable from C.
Received counter-info by email, but maybe I was just too casual in the
definition of the shortcoming. I would love to learn I am mistaken, tho.
Specifically, I need to call a C function, say "establishCallback",
with a pointer to a Lisp function, say "os-event-handler", which will
then be called by C periodically to handle OS events after I give
control to the GLUT via one last call (in my main line code) to the C
"glutMainLoop" function.
An example from da code:
(ff:defun-foreign-callable mousedown-callback (button up-or-down x y)
(cello-do-mousedown button up-or-down x y)))
(defun main ()
(glut-mouse-func (ff:register-foreign-callable mousedown-callback))
(glut-main-loop))
Notice I am using ACL's ff: package instead of uffi cuz uffi don't play
foreign callbacks, because not everyone can handle them. Hang on, maybe
I misremembered which implementation came up short in this regard?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Hello!
Kenny Tilton <·······@nyc.rr.com> wrote:
>[...]
>Notice I am using ACL's ff: package instead of uffi cuz uffi don't play
>foreign callbacks, because not everyone can handle them. Hang on, maybe
>I misremembered which implementation came up short in this regard?
Perhaps uffi should be extended to support callbacks on those platforms
which provide enough for that support.
I.e. if your platform has callbacks, you can use them in a unified
way via UFFI, if not, you've still lost, but are no worse than before.
Kind regards,
Hannah.
Hannah Schroeter wrote:
> Hello!
>
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>>[...]
>
>
>>Notice I am using ACL's ff: package instead of uffi cuz uffi don't play
>>foreign callbacks, because not everyone can handle them. Hang on, maybe
>>I misremembered which implementation came up short in this regard?
>
>
> Perhaps uffi should be extended to support callbacks on those platforms
> which provide enough for that support.
kevin (uffi's author) may jump in for himself, but as of now an explicit
design parameter is "universal-only".
hey, maybe instead CMUCL should get foreign callbacks working. (if my
understanding is correct that they are not.)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
>>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
Kenny> Hannah Schroeter wrote:
>> Hello!
>> Kenny Tilton <·······@nyc.rr.com> wrote:
>>
>>> [...]
>>
>>> Notice I am using ACL's ff: package instead of uffi cuz uffi don't play
>>> foreign callbacks, because not everyone can handle them. Hang on, maybe
>>> I misremembered which implementation came up short in this regard?
>> Perhaps uffi should be extended to support callbacks on those
>> platforms
>> which provide enough for that support.
Kenny> kevin (uffi's author) may jump in for himself, but as of now an
Kenny> explicit design parameter is "universal-only".
Kenny> hey, maybe instead CMUCL should get foreign callbacks working. (if my
Kenny> understanding is correct that they are not.)
How does this change the uffi "universal-only" design parameter? Or
does "universal" mean just a specific universe?
Ray
>>>>> "kt" == Kenny Tilton <·······@nyc.rr.com> writes:
kt> hey, maybe instead CMUCL should get foreign callbacks working. (if my
kt> understanding is correct that they are not.)
there's a detailed example of calling Lisp from C in CMUCL at
<URL:http://www.cons.org/cmucl/doc/tcl-callback.html>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
>>>>>>"kt" == Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>
>
> kt> hey, maybe instead CMUCL should get foreign callbacks working. (if my
> kt> understanding is correct that they are not.)
>
> there's a detailed example of calling Lisp from C in CMUCL at
>
> <URL:http://www.cons.org/cmucl/doc/tcl-callback.html>
>
Cool, thx much. I note "This implementation only works on the x86 port
using the conservative garbage collector. " Is that much of a
limitation? Anyway, looks like I can scrap the overhaul I had in mind to
switch Freeglut over to a polling mechanism.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
>>>>> "kt" == Kenny Tilton <·······@nyc.rr.com> writes:
ecm> <URL:http://www.cons.org/cmucl/doc/tcl-callback.html>
kt> Cool, thx much. I note "This implementation only works on the
kt> x86 port using the conservative garbage collector. " Is that
kt> much of a limitation?
that should actually read "generational garbage collector".
You should be fine with all distributed binaries of CMUCL on x86 platforms
(it's also possible to build CMUCL on x86 using a non-generational GC,
but there's not much point in doing so).
In fact, I just got that demo to work on CMUCL for SPARC, so I'll
update that web page.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
>>>>>>"kt" == Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>
>
> ecm> <URL:http://www.cons.org/cmucl/doc/tcl-callback.html>
>
> kt> Cool, thx much. I note "This implementation only works on the
> kt> x86 port using the conservative garbage collector. " Is that
> kt> much of a limitation?
>
> that should actually read "generational garbage collector".
>
> You should be fine with all distributed binaries of CMUCL on x86 platforms
> (it's also possible to build CMUCL on x86 using a non-generational GC,
> but there's not much point in doing so).
>
> In fact, I just got that demo to work on CMUCL for SPARC, so I'll
> update that web page.
>
Great. Well, sounds like the number of Lispers who won't be able to use
FreeGlut with callbacks will be negligible enough that my energies
should go elsewhere. If it really becomes an issue those folks can be
picked up later by hacking FG or, hell, porting it to CL (which is bound
to happen anyway).
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Kenny Tilton wrote:
>> Not sure what to do about CMUCL not being callable from C.
>
> Received counter-info by email, but maybe I was just too casual in the
> definition of the shortcoming. I would love to learn I am mistaken,
> tho.
In released versions of CMUCL (18d and previous) and in SBCL, it has
the status ``can be done but is "unsupported"''
It's a bit raw nuts'n'bolts: the callback that you register with GLUT
needs to call funcall0(address_of_os-event-handler). There are also
similar funcall1, funcall2, funcall3 which take additional arguments
and pass them onto the Lisp function. The arguments must be
'lispobjs' - appropriately tagged 32 bit words.
Potentially you have GC issues - if the GC moves your os-event-handler
function, everything goes boom. You can avoid this by running PURIFY
after loading that function, which will lock it (and everything else)
into read-only space after which it never gets moved again. Or you
could add a post-GC hook to update the C space pointer to the
function, but without thinking about it carefully I'd assume it would
turn out to be racey.
So, like I said, a bit raw still.
The current development version of CMUCL has a new feature called
'linkage tables', which changes a lot of symbol resolution stuff in
the runtime, and may impact this. I'm not running that though and
can't remember offhand. Ask on cmucl-help and someone is bound to
straighten you out.
> "Cells let us walk, talk, think, make love and realize
> the bath water is cold." -- Lorraine Lee Cudmore
Do you dither text when rendering? My tv remote control is getting
increasingly unreliable lately - I think it needs new AA cells.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> It's one more, isn't it?
>
> So now I have no choice but to buy a new Mac (maybe that 17in
> Powerbook), cuz I got that Spinal Tap reference from their page
> announcing X11 (via XFree86) for the Mac
Yep. Downloaded it, works great on my ancient 266 MHz PowerBook. I
already *had* XFree86 running on it, but Apple's X11.app
Xquartz/quartz-wm combo work far more smoothly and seemlessly and
better-integrated than XDarwin and OroborOSX even did. Startup time is
faster, performance is better, window manager is smoother, and memory
use is less.
I haven't tried an OpenGL X app yet, but I will, and it's supposed to be
accelerated.
> And just yesterday I discovered another promising tidbit: turns out
> /all/ graphics on OS X are produced via (wait for it) OpenGL!
As of OS X 10.2, yes. *IF* you've got appropriate 3D hardware. (recent
machines do, but mine doesn't)
Safari is also a little ripper of a browser. Based on Konquerer, but
goes about 50% better on the 266 PowerBook than Konquerer 1.98 does on
the 700 MHz Athlon (running SuSE) next to it. OK, that's old, but
Safari on that 266 also seems about the same speed as the Athlon 1800+
at work running whatever version of Konquerer comes with RedHat 8.
Of course that may change once Apple's patches get applied to Konquerer,
but in the meantime it's made a 4.5 year old laptop browse in a pretty
zippy way, which is something MSIE never managed.
-- Bruce
Kenny Tilton <·······@nyc.rr.com> writes:
> And just yesterday I discovered another promising tidbit: turns out
> /all/ graphics on OS X are produced via (wait for it) OpenGL! I had
> been wondering if that design choice (for Cello, the universal CL
> gui you all will be using soon) would hold up. Guess I can relax. :)
If it helps to relax you further, a number of application I use have a
GUI completely done in OpenGL. It makes portability a breeze.
For example, Massive (http://www.massivesoftware.com), used in
generating some of the scenes in Lord of the Rings, has the GUI
completely done in OpenGL - and this ported fairly painlessly to at
least one other platform than the original one it was developed on.
The downside of an OpenGL GUI is it's not a native GUI and thus looks
different from the native widget set on every platform.
Chris.
--
http://www.double.co.nz/cl