Dear William,
Thank you for you comments regarding SDL. Most of the mail I which I
receive about the Psychtoolbox concerns issues of how the Psychtoolbox
looks to users, which is fine, but it is refreshing to hear from
someone who takes an interest in how it works on the inside.
I address your comments one-by-one below. A few general remarks
however: I think your comments are all good ones, and I am surprised
by how closely they match what was my own reasoning on the subject a
while ago . I did create a partial, experimental, undistributed
version of the Psychtoolbox based on SDL. The experience of writing
that might have been necessary to realize that SDL was not the right
choice for the Psychtoolbox.
I am also copying this reply to the Psychtoolbox forum, in case there
are others who want to know the reasons why we abandoned the SDL API in
the OpenGL toolbox.
Psychtoolbox does not support multiple displays, and user feedback told
us that it should be there.
more reasonable choice before it became obvious that 2.0 was not going
to appear in the foreseeable future.
versions for Mac OS X, Windows and Linux by writing one version with
SDL, while retaining the majority, if not all, of the Psychtoolbox
features, then it was worth doing an SDL version first. To add in
residual features I could later improve SDL myself or abandon it and
use the native APIs.
The problems with that plan were:
- Even though SDL presents a more friendly face to the caller than
DirectX or Quickdraw, using SDL makes things harder, not easier. That
is because when things don't work correctly, SDL adds an new layer of
code to debug. And when debugging SDL you still have to understand the
underlying API, DirectX or QuickDraw. So it adds complexity, it does
not subtract complexity.
-The OS X version is top priority because, Apple has dropped OS 9. We
felt that first producing a thorough, usable version of the
Psychtoolbox for OS X based on CoreGraphics is preferred to
simultaneously producing three inadequate versions of the Psychtoolbox,
for Windows, OS X and Linux, based on SDL.
-Trusted displays are a vital feature of the Psychtoolbox and SDL makes
testing displays hard. With OS 9, Denis found that it is necessary to
validate video drivers for use in psychophysical displays. For every
use except psychophysics approximate adherence to specifications is
adequate. Only psychophysicists notice or care about subtle violations
of the specs, and some video driver bugs can go undetected by everyone
in the world except for Denis. The OS 9 toolbox has sophisticated
diagnostics which characterize the behavior of video drivers. Without
taking physical measurements of the screen, the best way to be assured
that what is specified precisely matches what is displayed is for the
Psychtoolbox to talk to the lowest level API directly, the one closest
to the video driver. That means not using SDL.
with Core Graphics , it compares well to SDL.
Best,
Allen
Thank you for you comments regarding SDL. Most of the mail I which I
receive about the Psychtoolbox concerns issues of how the Psychtoolbox
looks to users, which is fine, but it is refreshing to hear from
someone who takes an interest in how it works on the inside.
I address your comments one-by-one below. A few general remarks
however: I think your comments are all good ones, and I am surprised
by how closely they match what was my own reasoning on the subject a
while ago . I did create a partial, experimental, undistributed
version of the Psychtoolbox based on SDL. The experience of writing
that might have been necessary to realize that SDL was not the right
choice for the Psychtoolbox.
I am also copying this reply to the Psychtoolbox forum, in case there
are others who want to know the reasons why we abandoned the SDL API in
the OpenGL toolbox.
> The SDL may not be quite as quick as hand-tuned platform-dependentAgreed. Speed was not a reason for abandoning SDL.
> code, but given it's a pretty thin function-dispatch layer on top of
> same, I can't believe it is too slow for psychophysics applications.
> The main problem with SDL is lack of multi-monitor capabilities.We regard multi-monitor support to be an essential feature. The Win
Psychtoolbox does not support multiple displays, and user feedback told
us that it should be there.
> It should be pretty easy to hack it so you can choose which monitorAgreed.
> to send output to.
> On the other hand, you probably have no chance of getting SDL to runLack of multi-monitor support in SDL rules it out. SDL did seem like a
> on two monitors simultaneously. (SDL 2.0 promised to solve that
> problem, but I think its vaporware.)
more reasonable choice before it became obvious that 2.0 was not going
to appear in the foreseeable future.
> You can always think of SDL as another platform (but one that hasThat was plan A. I figured that if I could provide Psychtoolbox
> cross-platform capability). A sensible strategy that combines the
> benefits of both SDL and platform-dependent code is to first target
> the psych toolbox to SDL, giving instant reach to all major platforms
> (Mac, Win, Linux) and then going back and rewriting the code for each
> platform later. Another advantage is that SDL is better architected
> and easier to use* that most proprietary graphics systems (better than
> DirectDraw/DirectX and better than my memories of QuickDraw) so the
> SDL versions should be relatively fast to write.
versions for Mac OS X, Windows and Linux by writing one version with
SDL, while retaining the majority, if not all, of the Psychtoolbox
features, then it was worth doing an SDL version first. To add in
residual features I could later improve SDL myself or abandon it and
use the native APIs.
The problems with that plan were:
- Even though SDL presents a more friendly face to the caller than
DirectX or Quickdraw, using SDL makes things harder, not easier. That
is because when things don't work correctly, SDL adds an new layer of
code to debug. And when debugging SDL you still have to understand the
underlying API, DirectX or QuickDraw. So it adds complexity, it does
not subtract complexity.
-The OS X version is top priority because, Apple has dropped OS 9. We
felt that first producing a thorough, usable version of the
Psychtoolbox for OS X based on CoreGraphics is preferred to
simultaneously producing three inadequate versions of the Psychtoolbox,
for Windows, OS X and Linux, based on SDL.
-Trusted displays are a vital feature of the Psychtoolbox and SDL makes
testing displays hard. With OS 9, Denis found that it is necessary to
validate video drivers for use in psychophysical displays. For every
use except psychophysics approximate adherence to specifications is
adequate. Only psychophysicists notice or care about subtle violations
of the specs, and some video driver bugs can go undetected by everyone
in the world except for Denis. The OS 9 toolbox has sophisticated
diagnostics which characterize the behavior of video drivers. Without
taking physical measurements of the screen, the best way to be assured
that what is specified precisely matches what is displayed is for the
Psychtoolbox to talk to the lowest level API directly, the one closest
to the video driver. That means not using SDL.
> * on the better architected/easier point: SDL can initialiseYes, SDL is nice in that way. However I think Apple did a superb job
> everything in a few lines; in DirectX it takes 20-30 lines of
> incantations to initialise just the graphics system, and you can't
> work out which 20-30 lines to write - I always have to cut&paste an
> example and alter it to suit my own ends. SDL works on the principle
> that simple tasks should be easy and complicated tasks possible; this
> principle is not popular at Microsoft or Apple, where power and
> generality (at the expense of usability) seem to be what matters
with Core Graphics , it compares well to SDL.
Best,
Allen
On Wednesday, January 15, 2003, at 08:09 AM, William McIlhagga wrote:
> Hi, I read recently that you've decided to drop SDL as the underlying
> graphics engine for future versions of the psych. toolbox in favour of
> platform-dependent code. I don't think you should do that, and here's
> why:
>
> 1) The SDL may not be quite as quick as hand-tuned platform-dependent
> code, but given it's a pretty thin function-dispatch layer on top of
> same, I can't believe it is too slow for psychophysics applications.
>
> 2) The main problem with SDL is lack of multi-monitor capabilities. It
> should be pretty easy to hack it so you can choose which monitor to
> send output to. On the other hand, you probably have no chance of
> getting SDL to run on two monitors simultaneously. (SDL 2.0 promised
> to solve that problem, but I think its vaporware.)
>
> 3) You can always think of SDL as another platform (but one that has
> cross-platform capability). A sensible strategy that combines the
> benefits of both SDL and platform-dependent code is to first target
> the psych toolbox to SDL, giving instant reach to all major platforms
> (Mac, Win, Linux) and then going back and rewriting the code for each
> platform later. Another advantage is that SDL is better architected
> and easier to use* that most proprietary graphics systems (better than
> DirectDraw/DirectX and better than my memories of QuickDraw) so the
> SDL versions should be relatively fast to write.
>
> * on the better architected/easier point: SDL can initialise
> everything in a few lines; in DirectX it takes 20-30 lines of
> incantations to initialise just the graphics system, and you can't
> work out which 20-30 lines to write - I always have to cut&paste an
> example and alter it to suit my own ends. SDL works on the principle
> that simple tasks should be easy and complicated tasks possible; this
> principle is not popular at Microsoft or Apple, where power and
> generality (at the expense of usability) seem to be what matters
>
> Dr. William McIlhagga
> Optometry Dept. room F14
> Bradford University
> Great Horton Road
> Bradford BD7 1DP
> UK
> tel. (44) (1274) 235957
>