www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - SciD: the humble beginning

reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
I've just created a new dsource project and uploaded my collection of 
numerical routines. You can find it here:

   http://www.dsource.org/projects/scid

Hopefully others will find it useful as well. Most of the code is 
written with a "get it to work - NOW" philoshophy, and as such there is 
a lot of potential for improvement and polish, not least when it comes 
to performance. I am aware of this, so there is really no need to 
benchmark it against established scientific libraries quite yet. ;) More 
routines will be added as I write them (which is usually when I need 
them for work), and the existing ones will be polished whenever I have 
time to do so.

Huge thanks to Bill Baxter for letting me use his BLAS and LAPACK bindings!

Requirements:
   DMD 2.037
   BLAS and LAPACK libraries

-Lars
Dec 13 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article

 I've just created a new dsource project and uploaded my collection of
 numerical routines. You can find it here:
    http://www.dsource.org/projects/scid
 Hopefully others will find it useful as well. Most of the code is
 written with a "get it to work - NOW" philoshophy, and as such there is
 a lot of potential for improvement and polish, not least when it comes
 to performance. I am aware of this, so there is really no need to
 benchmark it against established scientific libraries quite yet. ;) More
 routines will be added as I write them (which is usually when I need
 them for work), and the existing ones will be polished whenever I have
 time to do so.
 Huge thanks to Bill Baxter for letting me use his BLAS and LAPACK bindings!
 Requirements:
    DMD 2.037
    BLAS and LAPACK libraries
 -Lars


This looks absolutely terrific given that it's a work in progress and all.  I
agree that we shouldn't be too obsessed with performance yet because:

1.  **Make it work**, make it right, make it fast.  We can always optimize it
later provided that there aren't any ridiculously bad design decisions.
2.  At least some of the time people (myself included) would rather a nice API
and
decent performance than an ugly API (read:  a straight Fortran or C API) and
lightening quick performance.

We've got the beginnings of a good matrix/numerics lib in your work.  I believe
that my dstats lib would provide just about all the statistical functionality a
good scientific lib would need, and I'm getting close to declaring it
beta-quality.  I'd say based on a quick look at what scipy has that we also need
the following for a credible full-fledged scientific lib:

Machine learning, i.e. classification and clustering.  (I'd probably be
qualified
to write that and was halfway thinking of breaking ground on it over Christmas
break.  However, I'm not committing to this yet, so if someone else already has
a
work in progress, let me know.  Also, there's a Java machine learning library
called Weka that I've used before.  It's very complete but the API is painful
and
it's GPL, so IDK if it'd be worth it to port to D.)

Optimization.  (A few people have tried but IDK if they've actually gotten far
off
the ground with it.)

Basic image I/O and processing.

Plotting.  I've considered doing this a few times, but I've decided it needs to
be
put off until D2 is stable and the GUI toolkits for it are reasonably stable. 
One
layer of instability (D2 itself) is workable, but two layers (D2 and the GUI
libs)
is not.
Dec 13 2009
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
dsimcha wrote:

 == Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article

 I've just created a new dsource project and uploaded my collection of
 numerical routines. You can find it here:
    http://www.dsource.org/projects/scid
 Hopefully others will find it useful as well. Most of the code is
 written with a "get it to work - NOW" philoshophy, and as such there is
 a lot of potential for improvement and polish, not least when it comes
 to performance. I am aware of this, so there is really no need to
 benchmark it against established scientific libraries quite yet. ;) More
 routines will be added as I write them (which is usually when I need
 them for work), and the existing ones will be polished whenever I have
 time to do so.
 Huge thanks to Bill Baxter for letting me use his BLAS and LAPACK bindings!
 Requirements:
    DMD 2.037
    BLAS and LAPACK libraries
 -Lars


 
 This looks absolutely terrific given that it's a work in progress and all.  I
 agree that we shouldn't be too obsessed with performance yet because:
 
 1.  **Make it work**, make it right, make it fast.  We can always optimize it
 later provided that there aren't any ridiculously bad design decisions.


A lot of the code is ported from 20-30 year old (i.e. extremely well 
tested) FORTRAN code, so any performance gains would be a bonus provided 
by the D language itself, and most likely not in the algorithms.

Also, if you spot any ridiculously bad design decisions, let me know. ;)



 2.  At least some of the time people (myself included) would rather a nice API
and
 decent performance than an ugly API (read:  a straight Fortran or C API) and
 lightening quick performance.


Yeah, that's what I think too. And, the way it is now, people who for 
some reason want to use the old-style api can just access the scid.ports 
functions directly.



 We've got the beginnings of a good matrix/numerics lib in your work.  I believe
 that my dstats lib would provide just about all the statistical functionality a
 good scientific lib would need, and I'm getting close to declaring it
 beta-quality.  I'd say based on a quick look at what scipy has that we also
need
 the following for a credible full-fledged scientific lib:
 
 Machine learning, i.e. classification and clustering.  (I'd probably be
qualified
 to write that and was halfway thinking of breaking ground on it over Christmas
 break.  However, I'm not committing to this yet, so if someone else already
has a
 work in progress, let me know.  Also, there's a Java machine learning library
 called Weka that I've used before.  It's very complete but the API is painful
and
 it's GPL, so IDK if it'd be worth it to port to D.)
 
 Optimization.  (A few people have tried but IDK if they've actually gotten far
off
 the ground with it.)
 
 Basic image I/O and processing.
 
 Plotting.  I've considered doing this a few times, but I've decided it needs
to be
 put off until D2 is stable and the GUI toolkits for it are reasonably stable. 
One
 layer of instability (D2 itself) is workable, but two layers (D2 and the GUI
libs)
 is not.


I agree with all of this. Here's a piece of advice to anyone who wants 
to try their hand at these and other things: There are a LOT of 
established and *extremely* well-tested numerical libraries lying around 
on the internet, and many of them are in the public domain. Instead of 
spending a lot of time re-inventing the wheel (I've tried it), port some 
old code and try to improve on it when you get it working. Here are a 
few starting points:

   http://www.netlib.org/
   http://gams.nist.gov/

And I forgot to say in my original announcement: I welcome contributors 
with open arms. I have no intention of making this a one-man show. If 
you want to contribute or participate in some way, let me know.

-Lars
Dec 13 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
dsimcha wrote:

 We've got the beginnings of a good matrix/numerics lib in your work.  I believe
 that my dstats lib would provide just about all the statistical functionality a
 good scientific lib would need, and I'm getting close to declaring it
 beta-quality.  I'd say based on a quick look at what scipy has that we also
need
 the following for a credible full-fledged scientific lib:


dstats has actually been kind of an inspiration for me. I've never used 
it, because I don't do any statistics, but I've looked through the API 
docs and the examples, and I really like the interface.



 Machine learning, i.e. classification and clustering.  (I'd probably be
qualified
 to write that and was halfway thinking of breaking ground on it over Christmas
 break.  However, I'm not committing to this yet, so if someone else already
has a
 work in progress, let me know.  Also, there's a Java machine learning library
 called Weka that I've used before.  It's very complete but the API is painful
and
 it's GPL, so IDK if it'd be worth it to port to D.)
 
 Optimization.  (A few people have tried but IDK if they've actually gotten far
off
 the ground with it.)
 
 Basic image I/O and processing.
 
 Plotting.  I've considered doing this a few times, but I've decided it needs
to be
 put off until D2 is stable and the GUI toolkits for it are reasonably stable. 
One
 layer of instability (D2 itself) is workable, but two layers (D2 and the GUI
libs)
 is not.


A few things that can be added to the list:

- special functions
- Fourier transforms
- Monte Carlo methods
- series
- least-squares fitting
- differential and integral equations

There is a good chance that I will need the latter for work just after 
the holidays, in which case I'll write it myself.

I'll add the above lists to the project home page.

-Lars
Dec 14 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
dsimcha Wrote:


 Plotting.  I've considered doing this a few times, but I've decided it needs
to be
 put off until D2 is stable and the GUI toolkits for it are reasonably stable. 
One
 layer of instability (D2 itself) is workable, but two layers (D2 and the GUI
libs)
 is not.
 


It would be unfair not to mention GtkD which nobody has done in your D2 GUI
libs thread. I think that so far it is the most mature and stable
cross-platform D2 GUI toolkit. It's been a year since it reached version 1.0,
so you should probably consider it. And GTK looks just fine on windows.
Dec 13 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Eldar Insafutdinov (e.insafutdinov gmail.com)'s article

 dsimcha Wrote:

 Plotting.  I've considered doing this a few times, but I've decided it needs
to be
 put off until D2 is stable and the GUI toolkits for it are reasonably stable. 
One
 layer of instability (D2 itself) is workable, but two layers (D2 and the GUI
libs)
 is not.


 It would be unfair not to mention GtkD which nobody has done in your D2 GUI
libs


thread. I think that so far it is the most mature and stable cross-platform D2
GUI
toolkit. It's been a year since it reached version 1.0, so you should probably
consider it. And GTK looks just fine on windows.

Is it fast and stable on D2?  You're right that noone specifically mentioned
it, I
just got the vibe that there's no reasonably stable D2 GUI lib yet.  If you
believe GtkD is stable enough to build other D2 libs on top of, that would be
great.

Also, correct me if I'm wrong, but I thought GTK made the tradeoff of being
XML-based and therefore relatively slow but more flexible.  I absolutely 150%
refuse to build a plotting library that chokes and takes a significant amount of
time to redraw complex plots when a window is resized or moved, no matter how
good
it looks, how many features it has, or how extensible it is.
Dec 13 2009
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
dsimcha Wrote:


 == Quote from Eldar Insafutdinov (e.insafutdinov gmail.com)'s article

 dsimcha Wrote:

 Plotting.  I've considered doing this a few times, but I've decided it needs
to be
 put off until D2 is stable and the GUI toolkits for it are reasonably stable. 
One
 layer of instability (D2 itself) is workable, but two layers (D2 and the GUI
libs)
 is not.


 It would be unfair not to mention GtkD which nobody has done in your D2 GUI
libs


 thread. I think that so far it is the most mature and stable cross-platform D2
GUI
 toolkit. It's been a year since it reached version 1.0, so you should probably
 consider it. And GTK looks just fine on windows.
 
 Is it fast and stable on D2?  You're right that noone specifically mentioned
it, I
 just got the vibe that there's no reasonably stable D2 GUI lib yet.  If you
 believe GtkD is stable enough to build other D2 libs on top of, that would be
great.
 
 Also, correct me if I'm wrong, but I thought GTK made the tradeoff of being
 XML-based and therefore relatively slow but more flexible.  I absolutely 150%
 refuse to build a plotting library that chokes and takes a significant amount
of
 time to redraw complex plots when a window is resized or moved, no matter how
good
 it looks, how many features it has, or how extensible it is.


GTK uses Cairo library for drawing and I don't think there should be any
trade-offs. GtkD contains bindings to Cairo and a few examples, but I haven't
tried it myself. As for its stability of D2 version - I can't be sure, as I
don't use it, but I've always thought it is reasonably stable. Developers of
GtkD should know better of course.

There were some benchmarks comparing drawing performance of Gtk and Qt, and Qt
was a magnitude faster. Also there has been done a lot of work on OpenGL
backend for Qt, which will make things even faster. And as I said earlier on Qt
already has plotting library Qwt (which is used for instance at the company I
am working for). But you'd have to wait for a month or so until we finish our
work.
Dec 13 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Eldar Insafutdinov (e.insafutdinov gmail.com)'s article

 dsimcha Wrote:

 == Quote from Eldar Insafutdinov (e.insafutdinov gmail.com)'s article

 dsimcha Wrote:

 Plotting.  I've considered doing this a few times, but I've decided it








needs to be

 put off until D2 is stable and the GUI toolkits for it are reasonably








stable.  One

 layer of instability (D2 itself) is workable, but two layers (D2 and the








GUI libs)

 is not.


 It would be unfair not to mention GtkD which nobody has done in your D2 GUI
libs


 thread. I think that so far it is the most mature and stable cross-platform D2
GUI
 toolkit. It's been a year since it reached version 1.0, so you should probably
 consider it. And GTK looks just fine on windows.

 Is it fast and stable on D2?  You're right that noone specifically mentioned
it, I
 just got the vibe that there's no reasonably stable D2 GUI lib yet.  If you
 believe GtkD is stable enough to build other D2 libs on top of, that would be




great.

 Also, correct me if I'm wrong, but I thought GTK made the tradeoff of being
 XML-based and therefore relatively slow but more flexible.  I absolutely 150%
 refuse to build a plotting library that chokes and takes a significant amount
of
 time to redraw complex plots when a window is resized or moved, no matter how
good
 it looks, how many features it has, or how extensible it is.


 GTK uses Cairo library for drawing and I don't think there should be any


trade-offs. GtkD contains bindings to Cairo and a few examples, but I haven't
tried it myself. As for its stability of D2 version - I can't be sure, as I
don't
use it, but I've always thought it is reasonably stable. Developers of GtkD
should
know better of course.

 There were some benchmarks comparing drawing performance of Gtk and Qt, and Qt


was a magnitude faster. Also there has been done a lot of work on OpenGL backend
for Qt, which will make things even faster. And as I said earlier on Qt already
has plotting library Qwt (which is used for instance at the company I am working
for). But you'd have to wait for a month or so until we finish our work.

I'm starting to get the feeling that the best way to figure out what GUI lib to
use would be to create a prototype of a very small portion of functionality
(maybe
just bare-bones scatter plots or something easy like that) in each lib and
benchmark it and see what the relative difficulty is.  The other option is to
make
sure everything is loosely coupled to the GUI lib so it can be easily swapped
for
another one.  The downside is that this has some tradeoffs in terms of
simplicity
and probably performance that I don't think I want to make and is probably a
classic example of overengineering.
Dec 13 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
dsimcha wrote:

 
 ...  The other option is to make
 sure everything is loosely coupled to the GUI lib so it can be easily swapped
for
 another one.  The downside is that this has some tradeoffs in terms of
simplicity
 and probably performance that I don't think I want to make and is probably a
 classic example of overengineering.


Is it really that hard to have the GUI libs in question just give you
some pixels in memory or an opengl context?  Then you could use your own
highly optimized plot drawing routines instead of relying on the GUI lib
to do this.  I figured this kind of thing would be unbeatable for
performance, unless the library ties your hands.
Dec 14 2009
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Chad J wrote:


 dsimcha wrote:

 
 ...  The other option is to make
 sure everything is loosely coupled to the GUI lib so it can be easily
 swapped for
 another one.  The downside is that this has some tradeoffs in terms of
 simplicity and probably performance that I don't think I want to make and
 is probably a classic example of overengineering.


 
 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context?  Then you could use your own
 highly optimized plot drawing routines instead of relying on the GUI lib
 to do this.  I figured this kind of thing would be unbeatable for
 performance, unless the library ties your hands.


If you are willing to do opengl (it's a bit more work) then I think that is 
a very good idea. Both QtD and GtkD should have good opengl interop, so you 
could at a later stage support both libraries.
Dec 15 2009
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:


 Chad J wrote:
 

 dsimcha wrote:

 
 ...  The other option is to make
 sure everything is loosely coupled to the GUI lib so it can be easily
 swapped for
 another one.  The downside is that this has some tradeoffs in terms of
 simplicity and probably performance that I don't think I want to make
 and is probably a classic example of overengineering.


 
 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context?  Then you could use your own
 highly optimized plot drawing routines instead of relying on the GUI lib
 to do this.  I figured this kind of thing would be unbeatable for
 performance, unless the library ties your hands.


 
 If you are willing to do opengl (it's a bit more work) then I think that
 is a very good idea. Both QtD and GtkD should have good opengl interop, so
 you could at a later stage support both libraries.


On second thought, you will lose performance dramatically on systems that 
don't have a good opengl driver / graphics card.
Dec 15 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Dec 15, 2009 at 1:00 AM, Lutger <lutger.blijdestijn gmail.com> wrot=
e:

 Chad J wrote:


 dsimcha wrote:

 ... =A0The other option is to make
 sure everything is loosely coupled to the GUI lib so it can be easily
 swapped for
 another one. =A0The downside is that this has some tradeoffs in terms o=






f

 simplicity and probably performance that I don't think I want to make a=






nd

 is probably a classic example of overengineering.


 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context? =A0Then you could use your o=




wn

 highly optimized plot drawing routines instead of relying on the GUI lib
 to do this. =A0I figured this kind of thing would be unbeatable for
 performance, unless the library ties your hands.


 If you are willing to do opengl (it's a bit more work) then I think that =


is

 a very good idea. Both QtD and GtkD should have good opengl interop, so y=


ou

 could at a later stage support both libraries.


Biggest problem with OpenGL is that the quality is crap for 2D stuff,
and quality really matters when you're trying to do something like
draw 2000 little markers on a plot and each is only 5 pixels wide.

Best you can do right now with GL without a lot of contortions is
something like 16x oversampling, but that only works on fairly recent
/ high-end cards (no chance on an intel integrated chipset, for
instance).  With analytical antialiasing you get 256 levels (vs just
16 with hardware AA).  The quality difference is very noticeable,
especially on plots with lots of fine lines and tiny markers.

--bb
Dec 15 2009
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Bill Baxter <wbaxter gmail.com> wrote:


 Biggest problem with OpenGL is that the quality is crap for 2D stuff,
 and quality really matters when you're trying to do something like
 draw 2000 little markers on a plot and each is only 5 pixels wide.

 Best you can do right now with GL without a lot of contortions is
 something like 16x oversampling, but that only works on fairly recent
 / high-end cards (no chance on an intel integrated chipset, for
 instance).  With analytical antialiasing you get 256 levels (vs just
 16 with hardware AA).  The quality difference is very noticeable,
 especially on plots with lots of fine lines and tiny markers.


You might get away with generating textures at 2-4 times the wanted
resolution, and generate mipmaps for the texture, then read from the
mipmap. Somewhat of a roundabout way of getting the image, but unless
you're using huge textures, it should work. (And even if you're using
huge textures, you can split the job. )

-- 
Simen
Dec 15 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Dec 15, 2009 at 3:22 PM, Simen kjaeraas <simen.kjaras gmail.com> wr=
ote:

 Bill Baxter <wbaxter gmail.com> wrote:


 Biggest problem with OpenGL is that the quality is crap for 2D stuff,
 and quality really matters when you're trying to do something like
 draw 2000 little markers on a plot and each is only 5 pixels wide.

 Best you can do right now with GL without a lot of contortions is
 something like 16x oversampling, but that only works on fairly recent
 / high-end cards (no chance on an intel integrated chipset, for
 instance). =A0With analytical antialiasing you get 256 levels (vs just
 16 with hardware AA). =A0The quality difference is very noticeable,
 especially on plots with lots of fine lines and tiny markers.


 You might get away with generating textures at 2-4 times the wanted
 resolution, and generate mipmaps for the texture, then read from the
 mipmap. Somewhat of a roundabout way of getting the image, but unless
 you're using huge textures, it should work. (And even if you're using
 huge textures, you can split the job. )


Yes, those are the kind of contortions I was talking about.  Or you
could do N passes, do a sub-pixel jitter of the camera each pass, and
accumulate.  Then you can essentially get whatever quality you want if
you're patient enough.

Or you could just use a library written for doing anti-aliased 2D graphics.

Best justification for using OpenGL, in my opinion, is in order to
facilitate support of 3D plotting at some point in the future.  That
seems to be difficult to retro-fit once you've gone deep down the 2D
rabbit hole.  At least Matplotlib (based on AGG) seems to be having
trouble getting anywhere with 3D plots.

--bb
Dec 15 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s article

 dsimcha wrote:

 ...  The other option is to make
 sure everything is loosely coupled to the GUI lib so it can be easily swapped
for
 another one.  The downside is that this has some tradeoffs in terms of
simplicity
 and probably performance that I don't think I want to make and is probably a
 classic example of overengineering.


 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context?  Then you could use your own
 highly optimized plot drawing routines instead of relying on the GUI lib
 to do this.  I figured this kind of thing would be unbeatable for
 performance, unless the library ties your hands.


I had considered this.  The biggest problem is font rendering.
Dec 15 2009
next sibling parent Michal Minich <michal.minich gmail.com> writes:
 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context?  Then you could use your
 own highly optimized plot drawing routines instead of relying on the
 GUI lib to do this.  I figured this kind of thing would be unbeatable
 for performance, unless the library ties your hands.
 


 I had considered this.  The biggest problem is font rendering.
 


on Windows, function CreateDIBSection can be used to create block of memory 
directly accessible by application, while it can be used for GDI functions, 
including text rendering. I use it in some D code, and it is quite easier 
to use than it may look from the docs.

http://msdn.microsoft.com/en-us/library/dd183494%28VS.85%29.aspx
Dec 15 2009
prev sibling next sibling parent Lukas Pinkowski <Lukas.Pinkowski web.de> writes:
dsimcha wrote:

 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context?  Then you could use your own
 highly optimized plot drawing routines instead of relying on the GUI lib
 to do this.  I figured this kind of thing would be unbeatable for
 performance, unless the library ties your hands.


 
 I had considered this.  The biggest problem is font rendering.


In case of Qt, you can use a QGraphicsView on an OpenGL-widget. You can draw 
a 'background' with OpenGL (your plot) and render text with 
QGraphicsTextItem.
Dec 15 2009
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
dsimcha wrote:

 == Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s article

 Is it really that hard to have the GUI libs in question just give you
 some pixels in memory or an opengl context?  Then you could use your own
 highly optimized plot drawing routines instead of relying on the GUI lib
 to do this.  I figured this kind of thing would be unbeatable for
 performance, unless the library ties your hands.


 
 I had considered this.  The biggest problem is font rendering.


I think Tom (h3r3t1c) has some good font drawing code laying around.
I've made some crappy font drawing code at some point.  It's quite
doable and the game developing peeps around here should have font
rendering code.  It seems to come with the territory.  Hopefully someone
won't mind sharing.  At the end of the day this probably just means
depending on FreeType2 and borrowing some code.

That and also what everyone else was saying.
Dec 15 2009
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
dsimcha wrote:

 =3D=3D Quote from Eldar Insafutdinov (e.insafutdinov gmail.com)'s artic=


le

 dsimcha Wrote:

 Plotting.  I've considered doing this a few times, but I've decided i=






t needs to be

 put off until D2 is stable and the GUI toolkits for it are reasonably=






 stable.  One

 layer of instability (D2 itself) is workable, but two layers (D2 and =






the GUI libs)

 is not.


 It would be unfair not to mention GtkD which nobody has done in your D=




2 GUI libs

 thread. I think that so far it is the most mature and stable cross-plat=


form D2 GUI

 toolkit. It's been a year since it reached version 1.0, so you should p=


robably

 consider it. And GTK looks just fine on windows.
=20
 Is it fast and stable on D2?  You're right that noone specifically ment=


ioned it, I

 just got the vibe that there's no reasonably stable D2 GUI lib yet.  If=


 you

 believe GtkD is stable enough to build other D2 libs on top of, that wo=


uld be great.

=20
 Also, correct me if I'm wrong, but I thought GTK made the tradeoff of b=


eing

 XML-based and therefore relatively slow but more flexible.  I absolutel=


y 150%

 refuse to build a plotting library that chokes and takes a significant =


amount of

 time to redraw complex plots when a window is resized or moved, no matt=


er how good

 it looks, how many features it has, or how extensible it is.


	Gtk itself isn't XML based, it is pure compiled C and therefore as=20
fast as your compiler can make it. The only thing that's XML in Gtk=20
is dynamic GUI loading: you can define your entire GUI through an=20
XML file and have it loaded dynamically by your program. And even in=20
that case, once the GUI is loaded it becomes again pure C. I don't=20
see why GtkD would be any different.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Dec 15 2009
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Lars T. Kyllingstad wrote:

 Most of the code is 
 written with a "get it to work - NOW" philoshophy, and as such there is 
 a lot of potential for improvement and polish, not least when it comes 
 to performance. I am aware of this, so there is really no need to 
 benchmark it against established scientific libraries quite yet.


I wish more of software were written with this attitude. Too many a 
promising project is abandoned because it is not "proper", 
"comprehensive", "neat", "polished", "cool", "impressive", "performant", 
"unique", "impressive", "trail-blazing", ... And the only one who loses 
is US. WE lose.

This is tantamount to quenching creativity, the very property that 
differentiates us from the aboriginals. But observe: not because they'd 
be inferior, but simply because such a big part of their existence is 
consumed by the very acts of finding food and shelter, that we take for 
granted, while we have the time to indulge in quests of remote rewards.

The difference between "the Nike philosophy" (just do it), and doing it 
"the day AFTER tomorrow, after proper design and deliberation", is not 
the same as between "Bill Gates' get it out now, who cares how crappy", 
and "wait 'till it's perfect".
Dec 21 2009
parent torhu <no spam.invalid> writes:
On 22.12.2009 1:44, Georg Wrede wrote:

 Lars T. Kyllingstad wrote:

  Most of the code is
  written with a "get it to work - NOW" philoshophy, and as such there is
  a lot of potential for improvement and polish, not least when it comes
  to performance. I am aware of this, so there is really no need to
  benchmark it against established scientific libraries quite yet.


 I wish more of software were written with this attitude. Too many a
 promising project is abandoned because it is not "proper",
 "comprehensive", "neat", "polished", "cool", "impressive", "performant",
 "unique", "impressive", "trail-blazing", ... And the only one who loses
 is US. WE lose.

 This is tantamount to quenching creativity, the very property that
 differentiates us from the aboriginals. But observe: not because they'd
 be inferior, but simply because such a big part of their existence is
 consumed by the very acts of finding food and shelter, that we take for
 granted, while we have the time to indulge in quests of remote rewards.

 The difference between "the Nike philosophy" (just do it), and doing it
 "the day AFTER tomorrow, after proper design and deliberation", is not
 the same as between "Bill Gates' get it out now, who cares how crappy",
 and "wait 'till it's perfect".


LOL WUT



Sorry, someone had to say it. :)
Dec 21 2009