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.

== 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.

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.

== 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.

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.

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.

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.

== 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.

>> 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

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.