Thanks for the feedback, Campbell!   Exactly what I was looking for.  Your experience with 3D Blender and OpenGL helps a great deal.


From: Campbell Barton <>
To: Thales <>;
Sent: Saturday, September 28, 2013 9:44 PM
Subject: Re: [Audacity-devel] OpenGL for Rendering Waveforms, etc?

On Sun, Sep 29, 2013 at 10:02 AM, Thales <> wrote:
> ________________________________
> From: Campbell Barton <>
> To: Thales <>;
> Sent: Saturday, September 28, 2013 4:19 AM
> Subject: Re: [Audacity-devel] OpenGL for Rendering Waveforms, etc?
> On Sat, Sep 28, 2013 at 1:18 AM, Thales <> wrote:
>> Hello Campbell,
>> I don't know off hand, but judging by the interfaces for packages like
>> Adobe
>> Audition and Pro Tools, I'm guessing they are using either DirectX or
>> OpenGL.
>> Here are several screenshots from both Audio Edition and Pro Tools:
>> The rich colors, sharp details, transparent images, free form layouts,
>> etc.,
>> make me think they're using OpenGL or DX!  :-)
>> Thanks,
>> ...John
> "Hi John, note that I'm not speaking as part of the Audacity team (I
> only did minor patches so far),
> but I think you approach it backwards."
>  Same here! :-)
> "Rather then say "theres a shiny technology - lets use it", Id approach
> from other direction.
> - Audacity is limited because "..."
> - It can be solved by "..." (improved drawing I assume?)
> - Improved/Advanced drawing can be achieved by "..."
> I'd actually be surprised if all the applications you linked to are
> using OpenGL/DirectX,
> Its quite feasible to have smooth lines without hardware acceleration."
>    Are you sure?  All graphics cards should supply OpenGL and DX drivers,
> since they are the standard libraries used for graphics for games and other
> graphically intense applications.  It would be very hard to do anything
> beyond the basics graphically without writing routines that are compatible
> across all cards.

Absolutely, Some drivers are so buggy its not funny, yet somehow
manage to run most games.
I've seen upside-down text because of broken drivers 2D functionality
on OSX, circles fail to draw completely because of bug in Mesa on
linux (reported).
Visualized systems fail in various ways other respects (VirtualBox/VMWare),

OpenGL and multiple windows can also be complicated since games are
not doing this much and it breaks on quite a lot of hardware
(especially Intel for some reason).

Switching GPU's (nvidia/intel) can cause problems with some applications too.

OpenGL has extensions to request if a feature is supported but some
drivers lie and you end up having to check vendor+driver versions.

+ Random crashes and even reboots at times though this is rare.

> "Also don't under estimate the potential of cheap laptop hardware and
> buggy drivers to perform baddly with OpenGL,
> especially 2D functions which are sometimes done in software anyway
> (cheap cards tend to do this since games don't use them)."
>    Well, games do use cheap cards.  It's just that if you want the cutting
> edge games you'll need a more high end card.

My point is the cheap cares are ONLY tested for simple functionality
(a generalization but my experience), OpenGL is a large spec and some
drivers don't properly implement the parts which casual gamers won't
notice missing,
sometimes the vendors release fixes later but you still have users
with old drivers who report bugs.

Also, You dont necessarily expect an audio application to require
OpenGL acceleration, if for some reason you run Audacity where
hardware acceleration isn't available (or is slow/broken), it would be
good if it were still usable (at least no slower then it is now).

> "It depends on the scope of the task but you might end up having to
> check for different opengl hardware and implement workarounds for
> known bugs. thats in fact very common in projects using OpenGL.
> Such bugs are incredible annoying since often the developers can't
> redo them and users complain that their interface is broken."
>    That's true.  Bugs will always be an issue.

Its not that bugs are an issue, (of course bugs are hard to completely avoid),
Its that you suddenly run into a class of hardware/driver related bugs
that you didnt have to deal with before and that you often can't debug
without that users specific configuration.

How many bugs you run into depends on your use of OpenGL, I'm just
pointing out that this aspect shouldn't be ignored.

> "Long term - I wouldn't assume this to be a straightforward task or
> even a net gain.
> Suggest you first define the problem - then solutions can be considered,
> though unless a developer plans to pick up this project, it probably
> ends up being a lot of noise with no outcome."
>    Well, this really came to me since I've been working on the pan envelope
> feature.    I've done quite a bit of work with graphics and OpenGL/DX, and
> thought that OpenGL would provide a great tool by which to create an
> effective pan envelope, and I see it working the same for many features.
> It would give you a practical advantage over WxWidgets in terms of
> flexibility of interface and quality renderings.  Quality renderings can
> improve functionality, because being able to see things in visual space
> clearly adds a lot.

I see where your coming from but still its best to show the
improvements and worry about how to implement after.

>  However, having said that, there is no doubt this wouldn't be a small
> change and there are always down sides.    I just wanted to throw this out
> there to see how people would respond.
>  Thanks for the feedback, Campbell!!
>  ...John

No worries, hope I don't come over as grumpy, but thinking back to hrs
spent on IRC remote troubleshooting with users only to find its a
driver bug, I don't really wish this on anyone :D