Re: OpenGL will never catch on

From: Rahul Jain (rjain_at_nyct.net)
Date: 04/18/04 

Date: Sun, 18 Apr 2004 16:08:50 GMT

Kenny Tilton <ktilton@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
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

Relevant Pages

  • Re: New Borland Delphi Survey
    ... AFAIK as far as 3D on mobile devices go, as most don't have hardware 3D acceleration yet, neither DirectX nor OpenGL are going to be effective, and custom software engines still reign supreme. ...
    (borland.public.delphi.non-technical)
  • Re: simple 3D app strictly in J#
    ... The site is fantastic, and i love the link, but somthing with hardware ... acceleration would be better for me, since i'm trying to build a fullscreen ... Or even OpenGL might work. ... DirectX or OpenGL in J#, ...
    (microsoft.public.dotnet.vjsharp)
  • Re: Further questions on OpenGL hardware acceleration
    ... surface will be faster than rendering directly to the DIBSECTION with OpenGL ... so hardware would just slow things down in any case. ... acceleration in FS2004? ...
    (comp.graphics.api.opengl)
  • Re: State of Linux graphics
    ... | implementation in place of existing X drivers. ... For the short term it's valuable for the apps that use OpenGL directly. ... R128-class hardware is fast enough to be useful ... developers than the former (and that's the point I was trying to make ...
    (Linux-Kernel)
  • Re: Display problems in Vista
    ... graphics hardware; you're not doing that with the current setup. ... the whole point of OpenGL is to provide a convenient way to draw ...
    (comp.graphics.api.opengl)