I once read a quotation something like "I like Lisp. It lets you feel
the bits between your toes." When I first read it, I thought "huh?",
and I haven't had any flashes of enlightenment since.
Digging for material, I found Drew McDermott on 2003/10/20: "I think I
was regretting the demise of the facility in many Lisps that let you
coerce a fixnum to a pointer and back again (just like C!). It was at a
talk given by Steele about what Common Lisp was shaping up to be like,
and I said that one nice thing about pre-Common Lisps was that 'you
could feel the bits between your toes' when you programmed in them. I
now think I was wrong." <-- This quote is taken out of context, so don't
beat up on Drew.
Ray Dillinger, a few days ago:
> Lisp presents an abstract machine that has to be considered as a mathematical
> entity, driven by theory; you can make it do anything, in its own terms, but
> its relationship to the physical entity (sequential memory machine, register
> CPU, etc) on your desk is at best tenuous and ill-defined. I wind up feeling
> clumsy, like I've got padded gloves on. It's just a perception; Lisp is
> still the best language there is for describing operations on _information_.
> But there's something unsatisfying about it, I guess, in that it doesn't
> describe operations on _the_machine_.
>
> I guess that was part of the reason I set out to implement my own Lisp;
> I wanted to have that feeling of precise control back, I wanted to know
> exactly what machine code and what byte representation every lisp operation
> and datum had. Instead, I can't shake the feeling that I just know more and
> more about the gloves I'm wearing that make me feel clumsy.
So Drew's quote gives me a bit of a clue: the pre-Common Lisps
apparently had a lot more "stuff" in them for low level programming.
I suffer from a bit of a (nah, a HUGE) mental disconnect when I read
about Lisp Machines with operating systems written entirely in Lisp,
perhaps because I've been trying to visualize just CL with, say,
primitives for reading and writing absolute memory locations and the CPU
interrupt flag. I think it would be a real bear (sorry Ray!) to write an
operating system with that for a tool. But I recognize that I'm coming
to this from a Linux kernel hacker's perspective, and that a Lisp
operating system would be a lot different.
What can I read to understand more about LispOS implementations and the
special features of the Lisps that helped them?
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> I once read a quotation something like "I like Lisp. It lets you feel
> the bits between your toes." When I first read it, I thought "huh?",
> and I haven't had any flashes of enlightenment since.
>
> Digging for material, I found Drew McDermott on 2003/10/20: "I think I
> was regretting the demise of the facility in many Lisps that let you
> coerce a fixnum to a pointer and back again (just like C!). It was at a
> talk given by Steele about what Common Lisp was shaping up to be like,
> and I said that one nice thing about pre-Common Lisps was that 'you
> could feel the bits between your toes' when you programmed in them. I
> now think I was wrong." <-- This quote is taken out of context, so don't
> beat up on Drew.
>
> Ray Dillinger, a few days ago:
>
>> Lisp presents an abstract machine that has to be considered as a
>> mathematical entity, driven by theory; you can make it do anything, in
>> its own terms, but its relationship to the physical entity (sequential
>> memory machine, register CPU, etc) on your desk is at best tenuous and
>> ill-defined. I wind up feeling clumsy, like I've got padded gloves
>> on. It's just a perception; Lisp is still the best language there is
>> for describing operations on _information_. But there's something
>> unsatisfying about it, I guess, in that it doesn't describe operations
>> on _the_machine_.
>>
>> I guess that was part of the reason I set out to implement my own
>> Lisp; I wanted to have that feeling of precise control back, I wanted
>> to know exactly what machine code and what byte representation every
>> lisp operation and datum had. Instead, I can't shake the feeling that
>> I just know more and
>> more about the gloves I'm wearing that make me feel clumsy.
>
>
> So Drew's quote gives me a bit of a clue: the pre-Common Lisps
> apparently had a lot more "stuff" in them for low level programming.
>
> I suffer from a bit of a (nah, a HUGE) mental disconnect when I read
> about Lisp Machines with operating systems written entirely in Lisp,
> perhaps because I've been trying to visualize just CL with, say,
> primitives for reading and writing absolute memory locations and the CPU
> interrupt flag. I think it would be a real bear (sorry Ray!) to write an
> operating system with that for a tool. But I recognize that I'm coming
> to this from a Linux kernel hacker's perspective, and that a Lisp
> operating system would be a lot different.
>
> What can I read to understand more about LispOS implementations and the
> special features of the Lisps that helped them?
You can read the links at
http://fare.tunes.org/LispM.html
to get some information. If you are intent of reading and feel like you
can afford it, you can order _Lisp Lore: A Guide to Programming the Lisp
Machine_.
http://tinyurl.com/2rngd
But I think nothing really does the job like actually sitting down to an
actual LispM and screwing with it for a while.
For what it's worth, you can get some (attenuated) idea by writing LAP
code routines in lisps that have LAPs (Lisp Assembler Programs). I
worked on SK8 at Apple for a while; it had some nontrivial parts at a
certain point written in LAP, mostly by David Vronay, whose chief stated
reason for liking Lisp was that he could write arbitrary functions in
assembler.
Cameron MacKinnon <··········@clearspot.net> wrote:
+---------------
| I once read a quotation something like "I like Lisp. It lets you feel
| the bits between your toes." When I first read it, I thought "huh?",
| and I haven't had any flashes of enlightenment since.
|
| Digging for material, I found Drew McDermott on 2003/10/20: "I think I
| was regretting the demise of the facility in many Lisps that let you
| coerce a fixnum to a pointer and back again (just like C!). ...
+---------------
Actually, I'll bet you'll still find such functions under the hoods
of almost all current Common Lisps' FFI facilities. For example, see
CMUCL's ALIEN:SAP-ALIEN and ALIEN:ALIEN-SAP macro/function (resp.):
SAP-ALIEN converts SAP (a system area pointer see section 6.5)
to an Alien value with the specified TYPE. TYPE is not evaluated.
ALIEN-SAP returns the SAP which points to ALIEN-VALUE's data.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Cameron MacKinnon <··········@clearspot.net> writes:
> What can I read to understand more about LispOS implementations and
> the special features of the Lisps that helped them?
Here's a recent paper:
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/Fjeld.pdf
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>What can I read to understand more about LispOS implementations and
>>the special features of the Lisps that helped them?
>
> Here's a recent paper:
> http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/Fjeld.pdf
I was aware of Movitz, but hadn't read much more than the website intro
and the changelog. Lazy of me! I was somewhat concerned that since the
history (presumably) went:
LispM Lisps -> (toes amputated) -> CL -> (just enough functionality
added) -> Movitz
...I wouldn't really get an idea of what programming a LispM OS would be
like just looking at Movitz. Yes, I know, a shameful number of
unwarranted assumptions. OK, guesses. And not saying I was aware of
Movitz in my OP was inexcusable.
Anyway, now I've read about Movitz (great work, Frode!) and am
confidently predicting that Cello will run on it this time next year.
It's already at the level where you can write a driver for your
favourite network card in Lisp.
Does anybody who still feels those phantom toes have any more pointers?
Thanks,
--
Cameron MacKinnon
Toronto, Canada
From: Rahul Jain
Subject: Re: Feeling the bits between your toes?
Date:
Message-ID: <87llku5ib4.fsf@nyct.net>
Cameron MacKinnon <··········@clearspot.net> writes:
> Anyway, now I've read about Movitz (great work, Frode!) and am
> confidently predicting that Cello will run on it this time next year.
> It's already at the level where you can write a driver for your
> favourite network card in Lisp.
*chuckle*
Then again. Lisp is good at AI (!), so maybe Kenny will write some code
to reverse-engineer the interfaces for any possible 3d accelerator cards.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>
>>Anyway, now I've read about Movitz (great work, Frode!) and am
>>confidently predicting that Cello will run on it this time next year.
>>It's already at the level where you can write a driver for your
>>favourite network card in Lisp.
>
>
> *chuckle*
>
> Then again. Lisp is good at AI (!), so maybe Kenny will write some code
> to reverse-engineer the interfaces for any possible 3d accelerator cards.
Cards? Kenny does not do hardware. Well, there was that regrettable
incident with a Cherry 2000...
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: Feeling the bits between your toes?
Date:
Message-ID: <87ad1aymsn.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> Cards? Kenny does not do hardware.
Hmm, maybe that's why he requires special hardware to be able to use his
library.
> Well, there was that regrettable incident with a Cherry 2000...
Do a talk about it at the next Lispnycs meeting!
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Cards? Kenny does not do hardware.
>
>
> Hmm, maybe that's why he requires special hardware to be able to use his
> library.
I do not know which is funnier, hearing OpenGL-compatible cards
described as special hardware or you not knowing about:
http://www.mesa3d.org/
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: Feeling the bits between your toes?
Date:
Message-ID: <871xmlycdu.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> Rahul Jain wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Cards? Kenny does not do hardware.
>> Hmm, maybe that's why he requires special hardware to be able to use
>> his
>> library.
>
> I do not know which is funnier, hearing OpenGL-compatible cards
> described as special hardware
Well, it's not available on any random computer you can find (maybe you
don't care about cheap low end machines, but they exist :). But as I
said before, if you want to be really strict about actually showing what
they're asked to show and not what they're not asked to show, very few
computers at all have OpenGL-compliant cards. But you seemed to find the
strange wedges in your perfect sphere to make it pretty, so I guess
you're happy about it. :)
> or you not knowing about:
>
> http://www.mesa3d.org/
What does that have to do with movitz? And what does it have to do with
_my_ 3D accelerator on _any_ OS? But if you can convince all the 3D card
vendors out there to open up their specs (I don't think _any_ of them
have their complete specs for their latest cards open any more... maybe
Matrox still publishes partial specs... or maybe they maintain
backwards-compatibility... and I think SiS or whoever owns the Savage
line these days might have published some specs... no idea about Intel's
horrid 3D "accelerators") because otherwise their users will install
Windows and curse at their vendor because they want to be able to use
Cello on movitz or on the latest linux releases, I'll be quite
impressed.
FWIW, I did try to get my 3D drivers installed on linux today. I
couldn't even get the source and proprietary GL lib installed. Looks
like I'm going to have to suffer through trying to use ATI's packages
again... and having to jump through hoops again every time I want to
upgrade XFree86. Grr. And for all I know, it'll still just blank out my
screen every time I start X.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Rahul Jain wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>Cards? Kenny does not do hardware.
>>>
>>>Hmm, maybe that's why he requires special hardware to be able to use
>>>his
>>>library.
>>
>>I do not know which is funnier, hearing OpenGL-compatible cards
>>described as special hardware
>
>
> Well, it's not available on any random computer you can find (maybe you
> don't care about cheap low end machines, but they exist :).
This is weird, an old fart like me looking to the future and a young pup
like you worrying about dusty old PC/XTs. Your bet against Cello is a
bet against the future of OpenGL. I have an open mind, but isn't that a
bad bet?
Well, i guess if you have to find a reason not to like Cello (and you
do) you haven't got much else other than posing as Defender of the VT100.
But as I
> said before, if you want to be really strict about actually showing what
> they're asked to show and not what they're not asked to show, very few
> computers at all have OpenGL-compliant cards. But you seemed to find the
> strange wedges in your perfect sphere to make it pretty, so I guess
> you're happy about it. :)
>
>
>>or you not knowing about:
>>
>> http://www.mesa3d.org/
>
>
> What does that have to do with movitz?
Sorry, did not realize you were still on topic. Why cannot Movitz use
Mesa3D? I see Movitz intends to offer typical OS services along with a
lisp implementation. Does that not include a graphics library?
And what does it have to do with
> _my_ 3D accelerator on _any_ OS? But if you can convince all the 3D card
> vendors out there to open up their specs (I don't think _any_ of them
> have their complete specs for their latest cards open any more... maybe
> Matrox still publishes partial specs... or maybe they maintain
> backwards-compatibility... and I think SiS or whoever owns the Savage
> line these days might have published some specs... no idea about Intel's
> horrid 3D "accelerators") because otherwise their users will install
> Windows and curse at their vendor because they want to be able to use
> Cello on movitz or on the latest linux releases, I'll be quite
> impressed.
In an attempt to understand you, I imagined the long parenthetical aside
was not there. The sentence got worse.
Why do we need vendor specs if we have the OpenGL spec? Are you talking
about pain and suffering in re using non-commercial OSes? Isn't pain and
suffering what non-commercial OSes do best?
>
> FWIW, I did try to get my 3D drivers installed on linux today. I
> couldn't even get the source and proprietary GL lib installed. Looks
> like I'm going to have to suffer through trying to use ATI's packages
> again... and having to jump through hoops again every time I want to
> upgrade XFree86. Grr. And for all I know, it'll still just blank out my
> screen every time I start X.
Get a Mac.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87u0zhwu3c.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> This is weird, an old fart like me looking to the future and a young pup
> like you worrying about dusty old PC/XTs. Your bet against Cello is a
> bet against the future of OpenGL. I have an open mind, but isn't that a
> bad bet?
It's interesting that you call a modern pentium system an XT. I'm not
betting against the existence of OpenGL. As a 3D API, it's rather good.
It's just not a very good bet for a _portable_ and _visually correct_
UI. It's great for creating cheap FPSes and for creating expensive 3D
modelling and rendering systems. Maybe Cello is secretly trying to be
that 3D FPS bootloader people were talking about at one time. :)
> Well, i guess if you have to find a reason not to like Cello (and you
> do) you haven't got much else other than posing as Defender of the VT100.
A VT100 may be the appropriate analogy with the timeframes appropriately
shifted. It wasn't the best terminal, but it was ubiquitous.
> Sorry, did not realize you were still on topic.
Cello on movitz was the topic. And movitz runs on hardware, some of
which doesn't have 3D acceleration.
> Why cannot Movitz use
> Mesa3D? I see Movitz intends to offer typical OS services along with a
> lisp implementation. Does that not include a graphics library?
Since when did Mesa3D work on any lisp graphics library? Or are you
volunteering to port ZETA-C to Movitz and add support for the linux
kernel API? Or do you assume that movitz is written in C from the start?
> And what does it have to do with
>> _my_ 3D accelerator on _any_ OS? But if you can convince all the 3D card
>> vendors out there to open up their specs (I don't think _any_ of them
>> have their complete specs for their latest cards open any more... maybe
>> Matrox still publishes partial specs... or maybe they maintain
>> backwards-compatibility... and I think SiS or whoever owns the Savage
>> line these days might have published some specs... no idea about Intel's
>> horrid 3D "accelerators") because otherwise their users will install
>> Windows and curse at their vendor because they want to be able to use
>> Cello on movitz or on the latest linux releases, I'll be quite
>> impressed.
>
> In an attempt to understand you, I imagined the long parenthetical aside
> was not there. The sentence got worse.
Your refusal to believe the reality of how 3D card vendors do their
business explains your delusions as to how portable a library that
requires a fast OpenGL implementation can be.
> Why do we need vendor specs if we have the OpenGL spec? Are you talking
> about pain and suffering in re using non-commercial OSes? Isn't pain and
> suffering what non-commercial OSes do best?
I dunno. Does MS Windows never have any bugs or deficiencies? Isn't
portability what you wanted? Or if you're serious about providing a
cheap, functional LispOS that pays the appropriate taxes to the various
hardware vendors, sign me up. (As a customer, not an employee. ;)
>> FWIW, I did try to get my 3D drivers installed on linux today. I
>> couldn't even get the source and proprietary GL lib installed. Looks
>> like I'm going to have to suffer through trying to use ATI's packages
>> again... and having to jump through hoops again every time I want to
>> upgrade XFree86. Grr. And for all I know, it'll still just blank out my
>> screen every time I start X.
>
> Get a Mac.
I thought you were more interested in targetting the more common
hardware. Stuff that some random person might have in their living room.
I also fail to see how getting a Mac would make linux drivers for the
video cards shipped with Macs suddenly appear. Or is portability not
your one of your main goals?
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> >> FWIW, I did try to get my 3D drivers installed on linux today. I
> >> couldn't even get the source and proprietary GL lib installed. Looks
> >> like I'm going to have to suffer through trying to use ATI's packages
> >> again... and having to jump through hoops again every time I want to
> >> upgrade XFree86. Grr. And for all I know, it'll still just blank out my
> >> screen every time I start X.
> >
> > Get a Mac.
>
> I thought you were more interested in targetting the more common
> hardware. Stuff that some random person might have in their living room.
> I also fail to see how getting a Mac would make linux drivers for the
> video cards shipped with Macs suddenly appear. Or is portability not
> your one of your main goals?
>
> :)
Isn't the common, random computer owning person using windows on a
machine with a 3d card?
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <874qrhw8tc.fsf@nyct.net>
····@free.fr (n++k) writes:
> Isn't the common, random computer owning person using windows on a
> machine with a 3d card?
Depends if you're talking about accelerators or decelerators. :)
Most computers provide 3d acceleration. There are a few at the low end
that don't, or don't provide anything of value in that department. The
accuracy of the rendering is another question, and I'm sure those
decelerators are even worse than, say, a Radeon 9600.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> ····@free.fr (n++k) writes:
>
> > Isn't the common, random computer owning person using windows on a
> > machine with a 3d card?
>
> Depends if you're talking about accelerators or decelerators. :)
>
> Most computers provide 3d acceleration. There are a few at the low end
> that don't, or don't provide anything of value in that department. The
> accuracy of the rendering is another question, and I'm sure those
> decelerators are even worse than, say, a Radeon 9600.
http://www.blender.org/modules/gfxdatabase/index.php
--
Blender OpenGL/Gfx Database
This is the OpenGL database of blender.org. Here we gather reports
from Blender users on the display quality of Blender's GUI, which is
entirely written in OpenGL.
Purpose is:
* To give us an overview of issues which need to be tackled,
sometimes a bypass can be coded.
* Give insight to Blender users which graphics card / OS / driver
combos perform best.
* Provide us statistics to contact 3D card driver developers with
errors they could fix.
Please note that the reports here are about quality; a proper display
of the user interface. It is not meant to compare Gfx card 3d
performance (speed)
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> ····@free.fr (n++k) writes:
>
> > Isn't the common, random computer owning person using windows on a
> > machine with a 3d card?
>
> Depends if you're talking about accelerators or decelerators. :)
>
> Most computers provide 3d acceleration. There are a few at the low end
> that don't, or don't provide anything of value in that department. The
> accuracy of the rendering is another question, and I'm sure those
> decelerators are even worse than, say, a Radeon 9600.
Let's be a bit reasonable. A GUI is what, a few textured triangles?
Even the crappy 3d cards present in old laptops like those ati rage
mobility chips can cope with an opengl gui with ease.
It's not likely you'd need something like render-to-texture in a gui.
(I just mention it because that's the only thing I know that wasn't
optimized well in old ~1997 range 3d cards)
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>This is weird, an old fart like me looking to the future and a young pup
>>like you worrying about dusty old PC/XTs. Your bet against Cello is a
>>bet against the future of OpenGL. I have an open mind, but isn't that a
>>bad bet?
>
>
> It's interesting that you call a modern pentium system an XT.
Oh, cmon, this is a flamewar, you think I am going to be intellectually
honest? Speaking of which, I hope by "modern" you mean "since XP came out".
> Cello on movitz was the topic. And movitz runs on hardware, some of
> which doesn't have 3D acceleration.
Oh. I get it. Cello sucks because it won't run on Movitz because Movitz
won't support OpenGL. Only on systems without OpenGL cards? You still
need gl and glu libs, even with the cards. No?
>
>
>>Why cannot Movitz use
>>Mesa3D? I see Movitz intends to offer typical OS services along with a
>>lisp implementation. Does that not include a graphics library?
>
>
> Since when did Mesa3D work on any lisp graphics library?
Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
try again. What plans does Movitz have now for graphics.
Or are you
> volunteering to port ZETA-C to Movitz and add support for the linux
> kernel API? Or do you assume that movitz is written in C from the start?
I just noticed Movitz today, so I have not had time to assume much. But
I hear you saying "Movitz cannot (will not?) do OpenGL". Yes? No?
> Your refusal to believe the reality of how 3D card vendors do their
> business explains your delusions as to how portable a library that
> requires a fast OpenGL implementation can be.
Who says Cello /requires/ a fast OpenGL implementation? I said the GPU
acceleration was a nice extra.
> ... Isn't
> portability what you wanted?
Portability to any serious Lisp or OS. A serious Lisp can call and be
called from C, a serious OS can run OpenGL.
>>Get a Mac.
>
>
> I thought you were more interested in targetting the more common
> hardware.
They're doing better. :) And it is a nice commercial market for the
stuff I want to sell.
> ... Or is portability not
> your one of your main goals?
let's just say I have scaled back as defined above, simply to be
practical. Cello has one developer, and that count can go down if I have
to go get a job. so for now the Lisp and the OS have to meet Cello halfway.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
One thing you might want to consider is that even brand new systems
don't do GL very well. Consumer-level hardware is designed mainly for
non-current OpenGL access (single intensive game or application), and
has performance issues balancing load from multiple apps. OpenGL can
be useful for a UI, but on existing hardware, the best way to utilize
it would be to define an abstract graphics API that spoke to an OpenGL
"server" over a protocol, so a single OpenGL context could be shared
by multiple apps.
Rayiner Hashem wrote:
> One thing you might want to consider is that even brand new systems
> don't do GL very well. Consumer-level hardware is designed mainly for
> non-current OpenGL access (single intensive game or application), and
> has performance issues balancing load from multiple apps. OpenGL can
> be useful for a UI, but on existing hardware, the best way to utilize
> it would be to define an abstract graphics API that spoke to an OpenGL
> "server" over a protocol, so a single OpenGL context could be shared
> by multiple apps.
That works?! Damn. Your hired. When can you start? My dream is to suck
in some unsuspecting OpenGL/Lisp whizkid and get on with Cells and the
widgets.
btw, I have found with the Glut that I /am/ able to use my internal
invalidation scheme (carried over from Mac/win32 environments which work
by update events) to avoid simply sitting there hogging the cpu
mindlessly spitting out frames while the user contemplates their next
ation. the Cpu load drops to negligible, until of course I start
dragging things around.
I am hoping this makes multiwindows apps viable. If not, I'll keep your
note in mind. Thx.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87brlovm2a.fsf@nyct.net>
·······@mindspring.com (Rayiner Hashem) writes:
> One thing you might want to consider is that even brand new systems
> don't do GL very well. Consumer-level hardware is designed mainly for
> non-current OpenGL access (single intensive game or application),
You mean _con_current?
> and has performance issues balancing load from multiple apps.
"Issues"? Mine doesn't even allow it in the first place. And I spent
$220 on the card at a discount mail-order place (and got a free upgrade
to boot).
> OpenGL can be useful for a UI, but on existing hardware, the best way
> to utilize it would be to define an abstract graphics API that spoke
> to an OpenGL "server" over a protocol, so a single OpenGL context
> could be shared by multiple apps.
Not just multiple, but _all_ apps if you want more than one app using
it. And you'd have to write your own windowing system.
Not to mention the hokey rendering artifacts you'll get on any cards
that cost less than $1000.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> > OpenGL can be useful for a UI, but on existing hardware, the best way
> > to utilize it would be to define an abstract graphics API that spoke
> > to an OpenGL "server" over a protocol, so a single OpenGL context
> > could be shared by multiple apps.
>
> Not just multiple, but _all_ apps if you want more than one app using
> it. And you'd have to write your own windowing system.
I am pretty sure this is EXACTLY what Quartz is on Mac OS X.
> Not to mention the hokey rendering artifacts you'll get on any cards
> that cost less than $1000.
Depending on what you do I expect. Meddle of Honor has shown off some
classic artifacts that I put down to its model. The normal Mac
behavior is, well, well behaved. Needless to say, I'm very impressed
by it.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
> > Not just multiple, but _all_ apps if you want more than one app using
> > it. And you'd have to write your own windowing system.
>
> I am pretty sure this is EXACTLY what Quartz is on Mac OS X.
Yep, this is what Quartz does. Except instead of a rendering protocol,
it has applications draw (via software) into a texture, and the
windowing system uses OpenGL to composit those. Since only the WM is
actually using OpenGL, it doesn't suffer with concurrency problems.
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87llktw9o0.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> Oh, cmon, this is a flamewar, you think I am going to be intellectually
> honest?
Yeah, but I figured I'd continue the flamewar, duh. If I just ignored
it, you wouldn't have much of a chance to flame back, would you? :P
> Speaking of which, I hope by "modern" you mean "since XP came out".
Yes.
>> Cello on movitz was the topic. And movitz runs on hardware, some of
>> which doesn't have 3D acceleration.
>
> Oh. I get it. Cello sucks because it won't run on Movitz because Movitz
> won't support OpenGL.
Nah, that's not why it sucks. :)
I was merely claiming that you won't be able to _usably_ use OpenGL on
movitz any better than you could use OpenGL with a Riva128. And that's
assuming you have the latest and greatest CPU. But at least you won't
get ugly rendering artifacts, even if you'll never stick around to look
at what's rendered. ;)
> Only on systems without OpenGL cards? You still need gl and glu libs,
> even with the cards. No?
Yes, and how on earth are you going to make those tolerably fast?
> Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
> try again. What plans does Movitz have now for graphics.
You can write whatever graphics drivers you want for it. Of course,
you'll need to wander around Silicon Valley with a ski mask and an Uzi
to do that, if you'd like to support most modern 3D accelerators.
> I just noticed Movitz today, so I have not had time to assume much.
But you assume that Mesa will do anything on it... In any case...
> But I hear you saying "Movitz cannot (will not?) do OpenGL". Yes? No?
No. Movitz will not be able to accelerate OpenGL to any reasonable speed
on any reasonably modern hardware without someone from the hardware
vendors' company actively recognizing the existence of Movitz and
budgeting a team to write drivers for it.
>> Your refusal to believe the reality of how 3D card vendors do their
>> business explains your delusions as to how portable a library that
>> requires a fast OpenGL implementation can be.
>
> Who says Cello /requires/ a fast OpenGL implementation? I said the GPU
> acceleration was a nice extra.
Personally, I don't like waiting a second or so in order for the screen
to register that I've clicked on a button. Your tastes may vary.
>> ... Isn't portability what you wanted?
>
> Portability to any serious Lisp or OS. A serious Lisp can call and be
> called from C, a serious OS can run OpenGL.
Of course. A serious OS is only those that have gotten special attention
from overprotective 3D hardware vendors.
>> ... Or is portability not your one of your main goals?
>
> let's just say I have scaled back as defined above, simply to be
> practical. Cello has one developer, and that count can go down if I have
> to go get a job. so for now the Lisp and the OS have to meet Cello
> halfway.
You forgot about the hardware and the OS's support for the hardware. :)
An OS can provide an OpenGL implementation, the hardware can provide
OpenGL acceleration, but that doesn't mean that the user will get a
usable OpenGL application if the window has any textures or more than a
hundred polygons.
But it's ok. We have CLIM, which works for all of these situations and
looks exactly how the user has configured the toolkit being used.
Good luck with your 3D Swing-in-Lisp, in any case.
Now where's that bill? ... 15 times ... carry the two ...
;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
>>try again. What plans does Movitz have now for graphics.
>
>
> You can write whatever graphics drivers you want for it.
How practical. Where /is/ Peter's book?!
> Personally, I don't like waiting a second or so in order for the screen
> to register that I've clicked on a button. Your tastes may vary.
Hey, if the screen then displays "Sleep of 980 milliseconds completed",
why not?
>
>
>>>... Isn't portability what you wanted?
>>
>>Portability to any serious Lisp or OS. A serious Lisp can call and be
>>called from C, a serious OS can run OpenGL.
>
>
> Of course. A serious OS is only those that have gotten special attention
> from overprotective 3D hardware vendors.
Let me guess. You are the Movitz developer assigned to OpenGL
compatibility, aren't you? I can help with the ski masks.
> But it's ok. We have CLIM,...
Surprise, surprise! Which backend? CLIM->CLX->???
which works for all of these situations and
> looks exactly how the user has configured the toolkit being used.
As long as its 24x80 ascii text in Courier?
>
> Good luck with your 3D Swing-in-Lisp, in any case.
Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
know a good library?) I expect to lose what remaining contact with
reality I have.
Speaking of which, time to go skating. Good luck with Movitz as well,
looks like a cool project.
>
> Now where's that bill? ... 15 times ... carry the two ...
Bad news. Since Westside Brewery adds the tip automatically, we have
eliminated your job. Can you do Java?
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Cesar Rabak
Subject: Re: OpenGL will never catch on --
Date:
Message-ID: <4082C9A5.5080604@acm.org>
Kenny Tilton escreveu:
>
[snipped]
>
> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
> know a good library?) I expect to lose what remaining contact with
> reality I have.
If you really want to do this someday you'll need to go after a case by
case (OS by OS) solution :-|
But I know you're kidding ;-D so this is just a futile observation, right!?
Anyway, kudos for the development of cello so far!
--
Cesar Rabak
Cesar Rabak wrote:
> Kenny Tilton escreveu:
>
>>
> [snipped]
>
>>
>> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
>> know a good library?) I expect to lose what remaining contact with
>> reality I have.
>
>
> If you really want to do this someday you'll need to go after a case by
> case (OS by OS) solution :-|
Yes, I would love to lose the Glut. Or port it to Lisp. But this Open
Source Fairy is already maxxed out and thinking dark thoughts about
focusing on a specific app instead of providing a GUI for a bunch of
ungrateful yabos, so let's stay Practical. With Frode (sp?) doing great
things with Movitz tunnelling from the other direction, maybe we can
meet up sometime for a drop dead Lisp OS.
If only Rahul would stop whining and get on with the OpenGL drivers.
>
> But I know you're kidding ;-D so this is just a futile observation, right!?
Kidding? About OpenAL or losing my mind or...? Anyway, no, it is not
futile at all, I am pencilling you in for the native OS X implementation.
>
> Anyway, kudos for the development of cello so far!
A grateful yabo! Well, thanks.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: OpenGL will never catch on --
Date:
Message-ID: <87y8osu68b.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> If only Rahul would stop whining and get on with the OpenGL drivers.
Where's the budget for my army? A small airforce would be a huge help,
too. Don't think marines would help much, since they're mostly solidly
in the valley. Maybe some paratroopers will be the key.
>> But I know you're kidding ;-D so this is just a futile observation,
>> right!?
>
> Kidding? About OpenAL or losing my mind or...?
Of course you couldn't be kidding about losing your mind. I should know,
I've already lost mine.
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain
Subject: Re: OpenGL will never catch on --
Date:
Message-ID: <87fzb0vm9l.fsf@nyct.net>
Cesar Rabak <······@acm.org> writes:
> Kenny Tilton escreveu:
>
>> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
>> know a good library?) I expect to lose what remaining contact with
>> reality I have.
>
> If you really want to do this someday you'll need to go after a case by
> case (OS by OS) solution :-|
>
> But I know you're kidding ;-D so this is just a futile observation, right!?
You misunderestimate Kenny. :)
He's already on an OS by OS solution with his attempt at using OpenGL.
But OpenAL is more likely to be supported more uniformly (I hope).
Text-to-speech shouldn't be a problem. It's just generating a waveform
which you throw at your sound drivers (OpenAL, in this case).
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87k70cvmg9.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
>>>Portability to any serious Lisp or OS. A serious Lisp can call and be
>>>called from C, a serious OS can run OpenGL.
>> Of course. A serious OS is only those that have gotten special
>> attention
>> from overprotective 3D hardware vendors.
>
> Let me guess. You are the Movitz developer assigned to OpenGL
> compatibility, aren't you? I can help with the ski masks.
Nope.
>> But it's ok. We have CLIM,...
>
> Surprise, surprise! Which backend? CLIM->CLX->???
"Which backend?" is exactly the question that implies you already know
the answer.
> which works for all of these situations and
>> looks exactly how the user has configured the toolkit being used.
>
> As long as its 24x80 ascii text in Courier?
Hah.
>> Good luck with your 3D Swing-in-Lisp, in any case.
>
> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
> know a good library?) I expect to lose what remaining contact with
> reality I have.
Eh, sound is at least decently standardized and commonly available. Even
though many on-board sound chips do silly things like warble when you
scroll in IE. At least they can turn off the speakers if it sounds bad.
:P
> Speaking of which, time to go skating. Good luck with Movitz as well,
> looks like a cool project.
Thanks, but wish Frode luck, not me. :)
>> Now where's that bill? ... 15 times ... carry the two ...
>
> Bad news. Since Westside Brewery adds the tip automatically, we have
> eliminated your job. Can you do Java?
Can I... Can I...
:-|
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> "Which backend?" is exactly the question that implies you already know
> the answer.
Answer? ease up on the paranoia, I do not even understand the question,
or how CLIM can run on Movitz. All I know about Movitz is that line
about running on the metal. x86, to be specific. I guess any computer
can draw to a screen via memory-mapped video, and come to think of it
that is how I wrote a game in assembler on the 6502, but I wager Movitz
wants to work a little higher than that. No C? yer gonna do FreeType in
Lisp?
I'm lost. Wanna throw me a frickin bone and just tell me?
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87fzb0tz5n.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> Rahul Jain wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>> "Which backend?" is exactly the question that implies you already know
>> the answer.
>
> Answer? ease up on the paranoia,
I'm not sure where you find paranoia here. Maybe that's the answer that
implies another answer. ;)
> I do not even understand the question, or how CLIM can run on Movitz.
The same way it runs on a whole boatload of platforms already, just like
CL. Note that your conflation of an implementation with a specification
is rather irritating.
> All I know about Movitz is that line about running on the metal. x86,
> to be specific. I guess any computer can draw to a screen via
> memory-mapped video, and come to think of it that is how I wrote a
> game in assembler on the 6502, but I wager Movitz wants to work a
> little higher than that.
Sure. What does that have to do with preventing a UI toolkit from
existing? McCLIM can just have a Movitz backend. (Actually backends for
whatever number of specific driver interfaces are implemented for
Movitz.)
Cello would use some sort of Lisp-intercepted OpenGL thing... or
something. I dunno how you'd structure it, since you don't have/need any
FFI. OpenGL seems only to make sense as a C interface, to me. Maybe
there's something more to it. The API would need to be different, of
course, since you're not calling C functions, but Lisp functions. Maybe
you have that stuff implemented separately for each platform anyway.
> No C? yer gonna do FreeType in Lisp?
Is plotting quadratic functions THAT hard?
> I'm lost. Wanna throw me a frickin bone and just tell me?
Heh. Tell you about what? The fact that we've said over and over again
that the current portedness of a portable interface has no bearing on
its portability? Or should I say that Cello will never run on Linux
because it didn't a month ago?
;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Rahul Jain wrote:
>>
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>"Which backend?" is exactly the question that implies you already know
>>>the answer.
>>
>>Answer? ease up on the paranoia,
>
>
> I'm not sure where you find paranoia here. Maybe that's the answer that
> implies another answer. ;)
>
>
>>I do not even understand the question, or how CLIM can run on Movitz.
>
>
> The same way it runs on a whole boatload of platforms already, just like
> CL. Note that your conflation of an implementation with a specification
> is rather irritating.
Sorry, I just flat out do not understand you, and I am sincerely trying
to do so. Anyway, I think we can drop it here. You may be right in your
position that OpenGL is an imperfect solution. Lispworks seems to have
the problem solved with native solutions. Please do not confuse me with
anyone of that size or technical strength. I am just an application
programmer who has moved from OS9 to WinNT and is looking forward to
getting back to OS X. All I have is Cells, which makes GUIs as much fun
to program as they usually are hell. Give me a bitmap and an event
stream to steer her by and Cells and I can give you a framework as good
as CLOS is relative to other OO models. For portability I looked at gtk
and openrm and coding up native each of the big three and I settled on
Glut and OpenGL as the best mix of power and practicality. the native
solution would be ideal, but would take too long and add too little
value to the Glut. It seems to be working, thank you very much.
Christophe will be happy to show you the Cello/Linux screenshot. That
was achieved by a Lisp newbie (albeit very strong Linux programmer) with
about three email questions to me which all tracked back to hardcoded
paths (eliminated in PortaCello3). And if UFFI "load-library" knew
Allegro ran on Linux, Frank would not have had to do the work he did.
He'll be submitting his stuff to UFFI.
Anyway, if the imperfections of Cello derive from imperfections in
OpenGL or its ubiquity, then those are the best imperfections to have.
Games and especially MMORPGs such as:
http://www.anarchy-online.com/
...are turbodriving OpenGL forward in performance and aesthetics. Look
also for 3D interfaces and screens to become de riguer for the
presentation of complex information.
Cello is hitched to that wagon, stuck with their imperfections (hair
coming through a wall?) but improving as they do, and this Open Source
Fairy does not have to lift a finger to get those ongoing benefits. Perfect.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote:
> Rahul Jain wrote:
>> The same way it runs on a whole boatload of platforms already, just like
>> CL. Note that your conflation of an implementation with a specification
>> is rather irritating.
> Sorry, I just flat out do not understand you, and I am sincerely
> trying to do so.
I think he's trying to hint at
a) CLIM being a backend-agnostic spec.
b) McCLIM having multiple backends: AFAICT currently at least
CLX, OpenGL and postscript, and even CLX running quite happily
on Windows given an X-server, which are a plethora.
Cheers,
-- Nikodemus
Kenny Tilton <·······@nyc.rr.com> writes:
> Rahul Jain wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
>>>try again. What plans does Movitz have now for graphics.
>> You can write whatever graphics drivers you want for it.
>
> How practical. Where /is/ Peter's book?!
It's coming; it's coming. Writing about pathnames sapped my will to
live but I'm bouncing back now.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
>>>>> "RJ" == Rahul Jain <·····@nyct.net> writes:
[...]
>> Only on systems without OpenGL cards? You still need gl and glu
>> libs, even with the cards. No?
RJ> Yes, and how on earth are you going to make those tolerably
RJ> fast?
They are already tolerably fast, IMHO. I use opengl mainly out of
convenience for mostly 2D stuff and even with P-IIIs and sw-only
implementations or win32 under vmware it is tolerably fast (in fact it
is fast enough that I dunno what it is I am tolerating).
[...]
RJ> Personally, I don't like waiting a second or so in order for
RJ> the screen to register that I've clicked on a button. Your
RJ> tastes may vary.
This doesn't sound right even adjusting for flamewar exaggeration.
Either Kenny is doing something very fancy for aesthetics or he
miscoded something in a particularly inefficient way. When I have
cycles to spare, I'll take a look. But he'll most likely fix it
before that.
[...]
RJ> An OS can provide an OpenGL implementation, the hardware can
RJ> provide OpenGL acceleration, but that doesn't mean that the
RJ> user will get a usable OpenGL application if the window has
RJ> any textures or more than a hundred polygons. [...]
I don't have any data on textures but glxgears gets ~250 fps on sw gl
under linux on a P4 2.6 + a 4 year old matrox card. That's more than
a few hundred polygons, no?
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "RJ" == Rahul Jain <·····@nyct.net> writes:
> [...]
> [...]
> RJ> An OS can provide an OpenGL implementation, the hardware can
> RJ> provide OpenGL acceleration, but that doesn't mean that the
> RJ> user will get a usable OpenGL application if the window has
> RJ> any textures or more than a hundred polygons. [...]
>
> I don't have any data on textures but glxgears gets ~250 fps on sw gl
> under linux on a P4 2.6 + a 4 year old matrox card. That's more than
> a few hundred polygons, no?
>
> cheers,
>
> BM
IIRC I can get 30 to 40 fps with Mesa on a Ultrasparc III 450 using
entirely software rendering w/ animation, texture and fog. Cut the
latter 2 and its considerably above 60- shrink the window and it goes
up from there. Not that 60 fps is all that wonderful, but these are
complex 3d scenes- not just windows.
If some OpenGL app drags with just a few hundred polygons, the problem
is almost certainly the software and not OpenGL.
Gregm
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87r7ukvmoc.fsf@nyct.net>
Greg Menke <··········@toadmail.com> writes:
> If some OpenGL app drags with just a few hundred polygons, the problem
> is almost certainly the software and not OpenGL.
I'm not sure how Kenny's doing the anti-aliased text in OpenGL, but
ignoring the effects of that, a few hundred polygons (e.g., 300) will
only allow a few dozen (i.e., 75) buttons on the screen. Note that a
scroll bar counts as 4 "buttons" (trough, slider, 2 buttons). That's
quite a small upper limit. All the apps I've created require about that
much UI complexity, at a minimum (although I have to guesstimate for the
effect of text, which was often a large portion of the UI). But hey, if
Kenny is slow enough coding up cello, maybe CPUs will get fast enough to
make it usable.
;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Greg Menke <··········@toadmail.com> writes:
>
>
>>If some OpenGL app drags with just a few hundred polygons, the problem
>>is almost certainly the software and not OpenGL.
>
>
> I'm not sure how Kenny's doing the anti-aliased text in OpenGL, but
> ignoring the effects of that, a few hundred polygons (e.g., 300) will
> only allow a few dozen...
who said OpenGL can only do 300 polygons. Jeex, one of my scroll bar
thumbs has that many.
(i.e., 75) buttons on the screen. Note that a
> scroll bar counts as 4 "buttons" (trough, slider, 2 buttons). That's
> quite a small upper limit. All the apps I've created require about that
> much UI complexity, at a minimum (although I have to guesstimate for the
> effect of text, which was often a large portion of the UI). But hey, if
> Kenny is slow enough coding up cello, maybe CPUs will get fast enough to
> make it usable.
Exactly. When does Movitz ship? Where will hardware be then? Why are you
clinging to the past? To justify a less capable GUI?
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Bulent Murtezaoglu wrote:
>>>>>>"RJ" == Rahul Jain <·····@nyct.net> writes:
>
> [...]
> >> Only on systems without OpenGL cards? You still need gl and glu
> >> libs, even with the cards. No?
>
> RJ> Yes, and how on earth are you going to make those tolerably
> RJ> fast?
>
> They are already tolerably fast, IMHO. I use opengl mainly out of
> convenience for mostly 2D stuff and even with P-IIIs and sw-only
> implementations or win32 under vmware it is tolerably fast (in fact it
> is fast enough that I dunno what it is I am tolerating).
>
> [...]
> RJ> Personally, I don't like waiting a second or so in order for
> RJ> the screen to register that I've clicked on a button. Your
> RJ> tastes may vary.
>
> This doesn't sound right even adjusting for flamewar exaggeration.
> Either Kenny is doing something very fancy for aesthetics or he
> miscoded something in a particularly inefficient way. When I have
> cycles to spare, I'll take a look. But he'll most likely fix it
> before that.
I do not think Rahul was making a bug report, I think it was just an
unfair, intellectually dishonest twisting of my words to win a flamewar.
So (a) I am glad to see I am having such a positive influence on the
lad, and (b) maybe everyone should put us in their killfiles.
That said, I have a long history of working without worrying about
performance until the app gets too slow to live with, and then I do a
Speed Week. I do not write slow code deliberately, but where I know I am
an ignoramus (OpenGL) I especially defer it as long as possible.
The slowest frame rate I observe is 10fps on the magnificent Light
Panel. This I believe is almost completely without display lists,
including all that antialiased text. display list utilization in Cello
comes and gos, the latter when I realize something did not change shape
because I have not made the display list Cells-aware and I end up using
obsolete lists. So why don't I do that?
As it is I can grab a 2d-slider puck tracked by an OpenGL light and
swing a spotlight smoothly around the screen, with lighting effects on
all the buttons drawn from scratch as well as the spinning 3d shape. A
simpler screen runs at 30fps, and even simpler screens have run at 100+
fps. So no Speed Week just yet.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> As it is I can grab a 2d-slider puck tracked by an OpenGL light and
> swing a spotlight smoothly around the screen, with lighting effects on
> all the buttons drawn from scratch as well as the spinning 3d shape. A
> simpler screen runs at 30fps, and even simpler screens have run at 100+
> fps. So no Speed Week just yet.
Uhm, I'm not sure I got the point: Does cello really /calculate/ the buttons
appearance? I mean in 3d?
I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
mainly for portability and rendering speed. Your not really planning to
make it (all) 3d, do you?
From the screenshots I've seen it's going to have a little 3d-stuff like
lighting. But I think this is in no way essential to a good gui toolkit and
therefore no argument for performance criticsm. If one would really have to
use a slow OpenGL-implementation this eye-candy could simply be turned off.
feel free to correct me
ts
Thomas Schilling <······@yahoo.de> writes:
> I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
> mainly for portability and rendering speed. Your not really planning to
> make it (all) 3d, do you?
As I understand it, Quartz Extreme under Mac OSX uses 3D exclusively
(even for 2D stuff) in order to take advantage of hardware
acceleration that is apparantly disappearing from the 2D ops.
OS X 10.3 on the later Apple hardware is a very good demo of what can
be done using OpenGL for all screen drawing operations.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> Thomas Schilling <······@yahoo.de> writes:
>
>
>>I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
>>mainly for portability and rendering speed. Your not really planning to
>>make it (all) 3d, do you?
>
>
> As I understand it, Quartz Extreme under Mac OSX uses 3D exclusively
> (even for 2D stuff) in order to take advantage of hardware
> acceleration that is apparantly disappearing from the 2D ops.
>
> OS X 10.3 on the later Apple hardware is a very good demo of what can
> be done using OpenGL for all screen drawing operations.
I think we had this discussion before, but I think it is imperative to
note that Cello goes further by using OpenGL primitives to build up the
frames eventually output by, again, OpenGL. The advantage is that I can
execute a kazillion instructions and have OpenGL compile them and
remember them as display-list 42. Then the CPU just has to yell out 42
to the GPU and away we go. the idea being less traffic to the card as
well as less work for the CPU the second time I render the same stuff.
What I do not know is how much is saved on the GPU by "compiling" a long
sequence of GL api calls.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> David Steuber wrote:
>
> > Thomas Schilling <······@yahoo.de> writes:
> >
> >>I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
> >>mainly for portability and rendering speed. Your not really planning to
> >>make it (all) 3d, do you?
> > As I understand it, Quartz Extreme under Mac OSX uses 3D exclusively
> > (even for 2D stuff) in order to take advantage of hardware
> > acceleration that is apparantly disappearing from the 2D ops.
> > OS X 10.3 on the later Apple hardware is a very good demo of what can
> > be done using OpenGL for all screen drawing operations.
>
> I think we had this discussion before, but I think it is imperative to
> note that Cello goes further by using OpenGL primitives to build up
> the frames eventually output by, again, OpenGL. The advantage is that
> I can execute a kazillion instructions and have OpenGL compile them
> and remember them as display-list 42. Then the CPU just has to yell
> out 42 to the GPU and away we go. the idea being less traffic to the
> card as well as less work for the CPU the second time I render the
> same stuff. What I do not know is how much is saved on the GPU by
> "compiling" a long sequence of GL api calls.
We've certainly had a similar discussion before.
I don't know the internals of OpenGL, so I can't say even where the
compiled display list data goes or what form it is in.
Mesa itself is an independent OpenGL implementation used on Linux.
Like X, it ultimately has to talk to the video hardware via its driver
at some point. It would probably be a pretty damn big job, but I
think it is possible to do an OpenGL implementation in Lisp. Then the
only FFI component is talking to the driver. I don't know how uniform
that API is. It would suck if the C code had a sperate backend for
each and every driver. That would mean that Lisp code would need the
same thing.
The only reason I would even suggest going with a pure Lisp (as is
possible) OpenGL implementation is for GC purposes. I'm sure that FFI
makes GC more interesting than it already is.
Regardless of ubiquity, I think that OpenGL *is* a good API to use.
While support may not be technically universal, I think it is
widespread enough to consider it accepted by the industry. Video
cards that support it are common in PC land and 100% on new Apple
computers. Software emulation is available at a rather considerable
performance penalty.
I think it would be safe to assume OpenGL on SGI boxes ;-)
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <874qrgtxbf.fsf@nyct.net>
David Steuber <·····@david-steuber.com> writes:
> Then the only FFI component is talking to the driver.
In linux, that "driver" is the DRM, whose interface is DRI.
> I don't know how uniform that API is.
...That is, assuming your driver is a DRM...
> It would suck if the C code had a sperate backend for
> each and every driver. That would mean that Lisp code would need the
> same thing.
You'd need an nvidia backend and a DRM backend. Hopefully a matrox one,
too (but there is also an open source DRM for their cards).
> The only reason I would even suggest going with a pure Lisp (as is
> possible) OpenGL implementation is for GC purposes. I'm sure that FFI
> makes GC more interesting than it already is.
Sure.
> Regardless of ubiquity, I think that OpenGL *is* a good API to use.
> While support may not be technically universal, I think it is
> widespread enough to consider it accepted by the industry. Video
> cards that support it are common in PC land and 100% on new Apple
> computers.
Too bad those cards can't draw things in the right places to save their
lives. But we can always spend $1000 to get a decent 3D ············@
> I think it would be safe to assume OpenGL on SGI boxes ;-)
They use Nvidia cards on the lower end boxes, last I checked.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Thomas Schilling wrote:
> Kenny Tilton wrote:
>
>
>>As it is I can grab a 2d-slider puck tracked by an OpenGL light and
>>swing a spotlight smoothly around the screen, with lighting effects on
>>all the buttons drawn from scratch as well as the spinning 3d shape. A
>>simpler screen runs at 30fps, and even simpler screens have run at 100+
>>fps. So no Speed Week just yet.
>
>
> Uhm, I'm not sure I got the point: Does cello really /calculate/ the buttons
> appearance? I mean in 3d?
Vanilla buttons are just 5 polygonse. A scroll bar thumb has a couple
hundred, I'd say.
>
> I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
> mainly for portability and rendering speed. Your not really planning to
> make it (all) 3d, do you?
I got carried away. But you don't get shaded buttons with lighting
unless the buttons are built of polygons. But I use an orthogonal
projection.
>
> From the screenshots I've seen it's going to have a little 3d-stuff like
> lighting. But I think this is in no way essential to a good gui toolkit and
> therefore no argument for performance criticsm. If one would really have to
> use a slow OpenGL-implementation this eye-candy could simply be turned off.
>
Well, if you want shaded buttons you gotta do something with polygons.
But, yes, I do not really have to use textures and emit light from
slider thumbs to do a nice scroll bar, I am just trying to show that
Cello will take Common Lisp "from worst to first" in GUI power.
My only quibble with what you wrote is that you give any credence at all
to the idea that OpenGL even in software might be slow. But let's read
the other messages and see what folks have to say.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87vfjwvmz0.fsf@nyct.net>
Thomas Schilling <······@yahoo.de> writes:
> From the screenshots I've seen it's going to have a little 3d-stuff like
> lighting. But I think this is in no way essential to a good gui toolkit and
> therefore no argument for performance criticsm. If one would really have to
> use a slow OpenGL-implementation this eye-candy could simply be turned off.
No, it's truely 3D. He's using 3D shapes to get the beveled edges you
see in toolkits today (as in not in the 1980s). With that, you need
lighting, of course, to get an actual beveled effect. Unless you want to
have a 1980s-looking UI like classic CLIM.
;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <87zn98vnas.fsf@nyct.net>
Bulent Murtezaoglu <··@acm.org> writes:
> They are already tolerably fast, IMHO. I use opengl mainly out of
> convenience for mostly 2D stuff and even with P-IIIs and sw-only
> implementations or win32 under vmware it is tolerably fast (in fact it
> is fast enough that I dunno what it is I am tolerating).
How many polys? What size textures? Antialiasing? Light sources?
Mip-mapping?
> [...]
> RJ> Personally, I don't like waiting a second or so in order for
> RJ> the screen to register that I've clicked on a button. Your
> RJ> tastes may vary.
>
> This doesn't sound right even adjusting for flamewar exaggeration.
> Either Kenny is doing something very fancy for aesthetics or he
> miscoded something in a particularly inefficient way. When I have
> cycles to spare, I'll take a look. But he'll most likely fix it
> before that.
He's getting 20-25 fps _with_ acceleration on a rather simple screen.
Less than a dozen sliders, a light source, and a rotating shape.
Hopefully most of that is cello's overhead, but I don't know what kind
of accelerator/decelerator he has.
> [...]
> RJ> An OS can provide an OpenGL implementation, the hardware can
> RJ> provide OpenGL acceleration, but that doesn't mean that the
> RJ> user will get a usable OpenGL application if the window has
> RJ> any textures or more than a hundred polygons. [...]
>
> I don't have any data on textures but glxgears gets ~250 fps on sw gl
> under linux on a P4 2.6 + a 4 year old matrox card. That's more than
> a few hundred polygons, no?
No, that's the example I had in mind. Note that there are no textures.
Also note that matrox cards 4 years ago were rather decently fast. Not
the fastest, but decent. 4-year-old matrox cards also aren't cheap even
now, but they're the best bet if you want halfway accurate rendering.
Full 2D texturing is just now becoming tolerable in a UI with recent,
mid-range hardware. But maybe Kenny's decided to target the market that
spends $2000 on their computers. Still, I can hardly tolerate dealing
with the speed of a fully textured UI. On the other hand, I find them to
be rather ugly, so I'm ok with that. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Bulent Murtezaoglu <··@acm.org> writes:
>
>
>>They are already tolerably fast, IMHO. I use opengl mainly out of
>>convenience for mostly 2D stuff and even with P-IIIs and sw-only
>>implementations or win32 under vmware it is tolerably fast (in fact it
>>is fast enough that I dunno what it is I am tolerating).
> He's getting 20-25 fps _with_ acceleration on a rather simple screen.
Without any attention to tuning, including OpenGL tuning, so.... the
numbers are meaningless, yes? Except that they /will/ get better.
I'd do a Speed Week, but I have enough experience to know performance is
not going to be a problem, so... not yet.
> Less than a dozen sliders, a light source, and a rotating shape.
Wow, we had you on Tip Duty? There are two lights, about 33 sliders,
each with a thumb. Three scroller widgets, a dozen buttons, and maybe
two-dozen anti-aliased text strings. If you consider that "a rather
simple screen", I don't want to see one of yours. But!...
> Hopefully most of that is cello's overhead,
Yep. Changing the shape from a cube to "Cello" as an extruded polygon
(which I can see is done with a kazillion polygons in wireframe mode and
in texturing) decrease the frame rate from like 10.5 to 9.8. Any other
shape made no difference, nor did tweaking the number of slices/stacks
used in constructing the shapes. Turning off the texture has no effect.
but I don't know what kind
> of accelerator/decelerator he has.
3ghz laptop. I'd go check my GPU, but I think we have ascertained
already that OpenGL is not the problem. As for Cello, hell, in this case
I would make the spinning shape a subwindow and watch the FPS go through
the roof.
Too easy?
> Full 2D texturing is just now becoming tolerable in a UI with recent,
> mid-range hardware. But maybe Kenny's decided to target the market that
> spends $2000 on their computers. Still, I can hardly tolerate dealing
> with the speed of a fully textured UI. On the other hand, I find them to
> be rather ugly, so I'm ok with that. :)
A $799 eMac comes with a radeon 9200 and 32mb DDR video memory. Good
graphics cards off the shelf are a ticket to a Broadway play. As for eye
candy, yeah, nobody likes the way Mac OS X looks. PWUAAUAAHHAHAHAHAH....
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "RJ" == Rahul Jain <·····@nyct.net> writes:
RJ> Bulent Murtezaoglu <··@acm.org> writes:
>> They are already tolerably fast, IMHO. I use opengl mainly out
>> of convenience for mostly 2D stuff and even with P-IIIs and
>> sw-only implementations or win32 under vmware it is tolerably
>> fast (in fact it is fast enough that I dunno what it is I am
>> tolerating).
RJ> How many polys? What size textures? Antialiasing? Light
RJ> sources? Mip-mapping?
Dunno, maybe 200 or so rectangles + 50 or so disks cones and such +
maybe 1kb of stroked text and some 200 or so lines. A few 64x64
textures (tiled). Only line anti-aliasing (hinted at best) 1 light
source. No mipmaps (I haven't learned about them!). This is with
debug 3 and no effort to increase performance under lispworks. Strict
GL 1.1 too. I do use display lists but I do it mostly out of
convenience (so there's a translate in a list called from the actual
draw-object list. That kind of indirection trick can't be efficient).
[...]
>> I don't have any data on textures but glxgears gets ~250 fps on
>> sw gl under linux on a P4 2.6 + a 4 year old matrox card.
>> That's more than a few hundred polygons, no?
RJ> No, that's the example I had in mind. Note that there are no
RJ> textures. Also note that matrox cards 4 years ago were rather
RJ> decently fast. Not the fastest, but decent.
Yeah but this is unaccelerated mesa, the most it can be using is
whatever 2D xfree acceleration is in the xfree matrox driver.
RJ> 4-year-old matrox
RJ> cards also aren't cheap even now, but they're the best bet if
RJ> you want halfway accurate rendering. [...]
I agree, the output driver seems much better than my newish ATi's.
The tiny text is much sharper at 1920x1440 with my G400 that it was
with the Ati 9200 on my sony CRT. It can't drive analog LCDs nearly
as well, alas.
cheers,
BM
From: Julian Stecklina
Subject: Re: OpenGL will never catch on
Date:
Message-ID: <86zn98g6eg.fsf@web.de>
Bulent Murtezaoglu <··@acm.org> writes:
> I don't have any data on textures but glxgears gets ~250 fps on sw gl
> under linux on a P4 2.6 + a 4 year old matrox card. That's more than
> a few hundred polygons, no?
I think glclock might be a better benchmark. But then again: Try
running Enemy Territory using software rendering...
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
All windows versions from win 98 on up ship with openGL.
Af for graphics acceleration this is supported by all modern
graphics cards. Hell I have a motherbord with integrated graphics
and it supports openGL just fine.
(Compaq Presario 2.4 GHz P4 256 Mb RAM)
P� Sun, 18 Apr 2004 10:56:53 GMT, skrev Kenny Tilton <·······@nyc.rr.com>:
>
> Rahul Jain wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >
> >>This is weird, an old fart like me looking to the future and a young
> pup
> >>like you worrying about dusty old PC/XTs. Your bet against Cello is a
> >>bet against the future of OpenGL. I have an open mind, but isn't that
> a
> >>bad bet?
> >
> >
> > It's interesting that you call a modern pentium system an XT.
>
> Oh, cmon, this is a flamewar, you think I am going to be intellectually
> honest? Speaking of which, I hope by "modern" you mean "since XP came
> out".
>
>
>> Cello on movitz was the topic. And movitz runs on hardware, some of
>> which doesn't have 3D acceleration.
>
> Oh. I get it. Cello sucks because it won't run on Movitz because Movitz
> won't support OpenGL. Only on systems without OpenGL cards? You still
> need gl and glu libs, even with the cards. No?
>
>>
>>
>>> Why cannot Movitz use
>>> Mesa3D? I see Movitz intends to offer typical OS services along with a
>>> lisp implementation. Does that not include a graphics library?
>>
>>
>> Since when did Mesa3D work on any lisp graphics library?
>
> Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
> try again. What plans does Movitz have now for graphics.
>
> Or are you
>> volunteering to port ZETA-C to Movitz and add support for the linux
>> kernel API? Or do you assume that movitz is written in C from the start?
>
> I just noticed Movitz today, so I have not had time to assume much. But
> I hear you saying "Movitz cannot (will not?) do OpenGL". Yes? No?
>
>
>> Your refusal to believe the reality of how 3D card vendors do their
>> business explains your delusions as to how portable a library that
>> requires a fast OpenGL implementation can be.
>
> Who says Cello /requires/ a fast OpenGL implementation? I said the GPU
> acceleration was a nice extra.
>
>> ... Isn't
>> portability what you wanted?
>
> Portability to any serious Lisp or OS. A serious Lisp can call and be
> called from C, a serious OS can run OpenGL.
>
>>> Get a Mac.
>>
>>
>> I thought you were more interested in targetting the more common
>> hardware.
>
> They're doing better. :) And it is a nice commercial market for the
> stuff I want to sell.
>
>> ... Or is portability not
>> your one of your main goals?
>
> let's just say I have scaled back as defined above, simply to be
> practical. Cello has one developer, and that count can go down if I have
> to go get a job. so for now the Lisp and the OS have to meet Cello
> halfway.
>
> kt
>
--
Sender med M2, Operas revolusjonerende e-postprogram: http://www.opera.com/
Cameron MacKinnon <··········@clearspot.net> writes:
> I suffer from a bit of a (nah, a HUGE) mental disconnect when I read
> about Lisp Machines with operating systems written entirely in Lisp,
> perhaps because I've been trying to visualize just CL with, say,
> primitives for reading and writing absolute memory locations and the
> CPU interrupt flag. I think it would be a real bear (sorry Ray!) to
> write an operating system with that for a tool. But I recognize that
> I'm coming to this from a Linux kernel hacker's perspective, and that
> a Lisp operating system would be a lot different.
>
> What can I read to understand more about LispOS implementations and
> the special features of the Lisps that helped them?
>
Sounds like this might be interesting to you then:
http://www.common-lisp.net/project/movitz/
http://www.cs.uit.no/~frodef/los0/
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel