dflplot 0.01

[dsimcha]

== Quote from Nick Sabalausky (a at a.a)'s article
> "Philippe Sigaud" <philippe.sigaud at gmail.com> wrote in message
> news:mailman.310.1278794218.24349.digitalmars-d-announce at puremagic.com...
> > On Sat, Jul 10, 2010 at 17:42, dsimcha <dsimcha at yahoo.com> wrote:
> >
> >>
> >> This is perfectly feasible, technically speaking.  I'm just not sure what
> >> it would
> >> buy practically speaking.  I kind of like the way x's and o's look.
> >> Maybe
> >> it
> >> would be faster for scatter plots with huge amounts of points, though.  I
> >> don't know.
> >>
> >> I don't know either. It's just it'd give access to some new shapes. But
> > don't bother, you've much more important things on your plate.
> >
> >
> >
> >> (parenthesis in doc)
> >> Thanks.  Fixed.
> >>
> >
> > This is a tiring bug in DDoc. I mean, why does it not generate a doc with
> > a
> > missing parenthesis?
> > (I guess that's filed as bug 3554)
> >
> >
> > > As for bitmaps, I have a small module that load 24 bit RGB .bmp as
> >> > ubyte[3][][] to manipulate them and write an ubyte[3][][] on disk, but
> >> it's
> >> > quite brittle. You indeed need a generic way to save a form to disk as
> >> > an
> >> > image.
> >>
> >> I really want saving to work, but I have no idea what I'm doing Win32
> >> API-wise.
> >> I'd say lack of saving support is by far the biggest outstanding issue
> >> with
> >> DFLPlot.  I'd appreciate any help in this regard.
> >>
> >
> > Halas, not from me: I'm at the same stage than you. At max, I'd know how
> > to
> > draw a graph on an empty bitmap, as long as it can be done by lighting
> > individual pixels. And then saving it to disk.  But putting text in it
> > (with
> > D or any other language) is beyond my ken.
> >
> > I used this technics for a ray-tracer in D and for drawing L-systems, to
> > learn D :-)
> > In fact, the only way I found to save the raytracer images to disk was to
> > manage them as a an array of ubyte[3] and writing this to disk as a 24-but
> > RGB .bmp file.
> >
> > I'll let Win32 wizards answer...
> >
> I'm no Win32 expert, but I've recently looked into this sort of thing for a
> potential side-project, and came up with a few links that might help:
> Bitmaps, Device Contexts and BitBlt
> http://www.winprog.org/tutorial/bitmaps.html
> Drawing Text
> http://msdn.microsoft.com/en-us/library/dd162490(v=VS.85).aspx
> Capturing an Image
> http://msdn.microsoft.com/en-us/library/dd183402(v=VS.85).aspx
> Windows GDI Documentation
> http://msdn.microsoft.com/en-us/library/dd145203(v=VS.85).aspx
> One thing to remember if you don't know already is that having direct
> pixel-by-pixel access involves using an HDIB (Device Independent Bitmap),
> and all the of built-in drawing functions (like drawing text) involve using
> a HDC (Device Context) insetad. (Also, HDIBs and HDCs are handles that get
> passed into free functions, they're not classes or structs.) So there does
> need to be some converting between HDC and HDIB. I assume "Capturing an
> Image" covers that, but I didn't look closely.


Yeah, this is what I tried to do.  I couldn't get it to work because the stuff
that needs to be defined in windows.d isn't.  Anyhow, I'm not going to waste too
much time on anything that requires directly messing w/ the Win32 API, since long
term this lib should be cross-platform anyhow (which might mean me porting dflplot
to gtkD) and there should be an easy way of converting a Bitmap to an array of
bytes in DFL w/o using the Win32 API directly (and hopefully this will get fixed).

If someone actually wrote me the code to get the bits out of a DFL Bitmap or
MemoryGraphics object and gave it to me under the Boost license or something
compatible, I'd absolutely include it and give credit, but it's not something I'm
going to put tons of effort into writing myself.