Python/C++ for graphics vs. other languages?

[Mark Wilson]

Doug Ball said

>I am very much enjoying learning and applying python,
however I find myself tasked with writing a potentially
large graphics intensive program that will we speed
sensitive.

>I would be grateful if any of you could share your
experiences with hybrid Python/C++ approaches to such
applications vs. using compiled high-level languages like
Dylan, Common Lisp or Objective Caml.

If you want to use Python as your user-interface glue - say
to control the graphics transformations your app can
perform, then I think you'll find it exceptionally
acceptable. In this capacity, success depends on how well
you can integrate the language (ie the interpreter) between
the bits and bobs the user sees and can fiddle with, and the
lumps of code which are actually generating/processing your
images. My own experience, though not directly concerned
with image processing, has been very positive. Python was
relatively easy to "connect" to both UI components and (in
my case fairly simple) processing code ( I say relatively -
mimicking an existing C++ class hierarchy in the Python
domain took a little head scratching). Having got the system
working, I've been amazed at the level of control you can so
easily express in the language, at the same time as I've
been mightily impressed by the speed at which it does these
things (in part of course due to the rate at which
processors can run these days).

Using Python to effect the actual image transformations on
the other hand would probably not be a good idea. If speed
is a sensitive issue, then I very much doubt you'll be
calculating pixel values in Python code (much as it would be
great to do so). However, you can probably break your
processes up into a suite of basic transformations
implemented in C/C++ (or whatever). You can endow with a
high degree of flexibility because its pretty easy to pass
lots of params from Python, and if your UI interface to the
language is good, then it will be easy for you to
specify/modify these params to get the most out of your
processing code. You could then use Python to orchestrate
sequences of these transformations to get the required
result.

Others may comment on performance relative to other
interpreted languages. I had the great misfortune to once
integrate AppleScript into a similar kind of framework. I
don't know if AppleScript actually qualifies as a language -
the computer equivalent of neanderthal grunts perhaps.
Whatever, it was a very long time ago, computers were slow
and AS was slow too, though most of the time you didn't
notice because you couldn't get anything to work right :->

My guess is that, once you start thinking about Python in
the middle of your app, and especially once you start to get
something that works, you'll be inspired to find neat ways
round any performance issues you may have. What you
definitly won't do is decide to ditch the language and do
the whole thing in C/C++ (or AppleScript for that matter).

Just my 2 pence worth.

Mark