[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gnash on ppc

On 6/5/06, Eddy Petrişor <eddy.petrisor@gmail.com> wrote:
On 6/5/06, Albert Cahalan <acahalan@gmail.com> wrote:
> On 6/2/06, Miriam Ruiz <little_miry@yahoo.es> wrote:
> > It seems you might be having some problem with OpenGL acceleration. Gnash uses
> > OpenGL right now for rendering, although Upstream is working on that too.
> If it relys on OpenGL, it ought to go in non-free. In general you'd be
> encouraging people to install proprietary video drivers from NVidia
> and ATI.

I think you are confusing 3D acceleration with OpenGL acceleration. I
have a ATI (Radeon mobility 9600) based PPC machine and I use the r300
free drivers and I have OpenGL acceleration.

In theory I could have low-end accelerated 3D at 800x512,
but I've yet to concoct a modeline that would get me into that
resolution with a Rage 128 PF/PRO AGP 4x TMDS and the
old 22" 1600x1024 Apple Cinema Display.

The free drivers have enough trouble with 2D. I get a horizontal
black line on my screen, 2 to 4 pixels thick, about 1 pixel below
the top of the screen. It's always been there in Linux, but not in
MacOS 9.

> These drivers would need x86 emulation on most of the
> platforms Debian supports, but nobody has yet been insane enough.

That kind of insanaty is not needed. Better use that energy, if
anybody thinks about it, to write the 3D acceleration part for the

Exactly how? Disassembly of the proprietary drivers? These are
not small drivers that just poke a few MMIO locations.

> C++ and OpenGL are not
> so good for anything that is supposed to run fast.

Where did you got that idea from? There is nothing wrong with C++ and
compilers have evolved that much that in some cases the code is
smaller and sometimes faster than the average code produced by a C

Most of the lag comes, usually, from a badly designed set of classes.

I've looked at disassembly. Finally gcc-4.1 manages to make std::min
not be way worse than the obvious macro, but you still lose the "restrict"
keyword and get extra crud for exception handling and all.

Then there is the matter of actually using the C++ features. There is no
point using a C++ compiler if you don't. I see things being done in STL
that should make any decent programmer want to cry.

Perhaps Bjarne can make C++ go fast. He's not on the project, is he?

About OpenGL and speed, can I say "huh"?!

If you have to render in software...

I have yet to find any use for 3D, yet more and more software is
written to needlessly require it. I can identify such apps easily
because they are excruciatingly slow. I seem to get about 2 FPS.

This is sick. The simple truth is that this makes most people
install proprietary video drivers. That's not an option for some
of us, either because we have non-x86 hardware or because
of some objection to non-free software.

Reply to: