Real time playback or not!

(This forum has been closed. Please use the General Moho Discussion forum.)

Moderators: Víctor Paredes, slowtiger

User avatar
cribble
Posts: 899
Joined: Wed Aug 04, 2004 12:42 pm
Location: London, UK
Contact:

Post by cribble »

Lost Marble, will there eventually be some sort of option to choose whether or not MoHo can use hardware acceleration?
--Scott
cribble.net
User avatar
Lost Marble
Site Admin
Posts: 2347
Joined: Tue Aug 03, 2004 6:02 pm
Location: Scotts Valley, California, USA
Contact:

Post by Lost Marble »

I can't give a definitive answer on any future changes to Moho. However, we have experimented with OpenGL acceleration, but there are a lot of things in Moho that just don't map well to OpenGL.
User avatar
cribble
Posts: 899
Joined: Wed Aug 04, 2004 12:42 pm
Location: London, UK
Contact:

Post by cribble »

OpenGL eh... is that a 3D app rendering system or something.. i think i've seen the word plastered over someones website. Is OpenGl software or hardware?
--Scott
cribble.net
RASH
Posts: 126
Joined: Sat Mar 19, 2005 10:27 am
Location: Netherlands

Post by RASH »

cribble wrote:OpenGL eh... is that a 3D app rendering system or something.. i think i've seen the word plastered over someones website. Is OpenGl software or hardware?
See here.

In simple terms: Open GL is a middleman between your computer's hardware and the program you're using (e.g. Moho).

Open GL contains fast routines to access the 2D and 3D hardware accelleration present in modern video adapters. The correct technical term for the kind of software as Open GL is an Application Program Interface (API), which means that software developers can include lines of code in their software which call specific routines of Open GL. The user (you) have no control over this, other than asking the software developer to include Open GL in their next update/version of your program.

Of course, software developers can write their own routines, but it is much easier (and less error prone) to use the Open GL API already developed and proven in practice. However, it may be necessary to rewrite a lot of code to implement Open GL in an existing non-Open GL program. This is a source of program errors in itself.

Just my $0.02.
myles
Posts: 821
Joined: Sat Aug 21, 2004 3:32 am
Location: Australia, Victoria, Morwell
Contact:

Post by myles »

Hi Cribble,

RASH's reply is absolutely correct, but I thought I'd flesh it out a little more (some of this is just a different explanation of the same thing written by RASH).

Applications (such as Moho) almost never write "direct-to-hardware" routines for hardware acceleration. If they did, they'd have to write separate low-level code for every version of every video chip/card, and (in some cases) separate code for each platform as well.

e.g.
routine to draw a line using Matrox G400 chip under Windows
routine to draw a line using nVidia XYZ chip under Linux
etc

As you'd imagine, this is impossible to support - the few programs that do this only run on a very limited subset of graphics chips/cards.

Libraries such as OpenGL allow a programmer to just say "draw a line, from point A to point B". The chip/card manufacturer supplies the OpenGL driver for their particular chip/card, and the driver translates from the generic standard OpenGL "draw a line" instruction into hardware-accelerated instructions for that particular card.

OpenGL is worth investigating because it is cross-platform.
Other similar libraries (DirectX, 3DR) are often not cross-platform, so you can't use them to support all three platforms (Mac, Windows, Linux) that Moho runs on.

The drawback: OpenGL is mostly written to support 3D acceleration, so while there may be hardware-accelerated routines to draw a polygon in 3D space and rotate it in 3D, there aren't usually any hardware-accelerated routines to e.g. draw variable width outlines around a curved shape.

Also, the OpenGL API is like a whole new programming language of its own, which operates in its own strange way. As RASH said, fitting this to an existing program can be a major rewrite, and may even a require a redesign of the program (e.g. a loss of useful features such as noisy fills/outlines because there's no way they can be supported by hardware acceleration, or writing and supporting separate routines for normal fills and noisy fills).

Then there's the problem where the hardware manufacturer's OpenGL supporting code has a bug (it happens) so you can't run Moho on that chip/card until it is fixed, if ever. Or the hardware manufacturer only writes partial support for OpenGL (which is quite a large specification), usually the parts needed to support 3D games - a problem I once ran into when trying to run a 3d program that used an OpenGL feature that was not found in most games of the time, so again your program can't run with that chipset and driver software.

Hardware acceleration can unfortunately be limiting as well as useful.

Regards, Myles.
"Quote me as saying I was mis-quoted."
-- Groucho Marx
User avatar
Banterfield
Posts: 138
Joined: Tue Aug 03, 2004 10:40 pm
Location: Colorado

Post by Banterfield »

myles wrote: or writing and supporting separate routines for normal fills and noisy fills).
Could we treat acceleration on a case by case basis, accelerating whenever possible? Definitely time-consuming work writing separate routines for ever case (as you hint at). But, man, if we could accelerate even one regularly used featured... the time savings would be awesome! :mrgreen: [he said, laughing at his own childlike enthusiasm]

I realized that we want an elegant and all encompassing solution, but I'd love a clever hack that'd speed things up where possible. Personally, I think shaving minutes off here and there during an export trumps real time playback any day of the week.
Dave
Locked