On Tue, Dec 15, 2009 at 1:00 AM, Lutger <lutger.blijdestijn@gmail.com> 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.

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

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.

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

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

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

On Tue, Dec 15, 2009 at 3:22 PM, Simen kjaeraas <simen.kjaras@gmail.com> wrote:
> 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. )

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