www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: simple display (from: GUI library for D)

reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Here's the D version using the direct to screen functions.



More little tasks for your module:
http://rosettacode.org/wiki/Fractal_tree#Python
http://rosettacode.org/wiki/Brownian_tree

The JavaScript processing port site has some more examples in the Demos section:
http://processingjs.org/exhibition

Bye,
bearophile
Apr 09 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 More little tasks for your module:
 http://rosettacode.org/wiki/Fractal_tree#Python



This one's use of recursion caused me to hit what I think is a
compiler bug. Not in the recursion itself, but in a struct's
copy constructor when it had a significant mixin.

I worked around it by declaring a private struct and using a pointer
to it rather than mixing in the implementation directly. I believe
this will be a net-positive too, since ScreenPainter is now
referenced counted.

Here's the implementation:

====
import simpledisplay;
import std.math;

void main() {
    // auto image = new Image(600, 600);
    auto window = new SimpleWindow(600, 600, "Fractal Tree");

    void drawTree(ScreenPainter p, in int x1, in int y1, in real angle, in int
depth) {
        if(depth == 0)
            return;
        immutable x2 = x1 + cast(int) (cos(angle) * depth * 10);
        immutable y2 = y1 + cast(int) (sin(angle) * depth * 10);
        p.drawLine(Point(x1, y1), Point(x2, y2));

        drawTree(p, x2, y2, angle - 0.35, depth - 1);
        drawTree(p, x2, y2, angle + 0.35, depth - 1);
    }

    drawTree(window.draw, 300, 550, -PI / 2, 9);
    window.eventLoop(0, (dchar) { window.close(); });
    // displayImage(image);
}

===

The reason Image is there, but commented out, is that such things
might be better done as images, then displayed once finished.
But, since we don't have drawing lines to images yet*, I went
direct to screen instead.

(well, I do have my implementation of Bresenham's algorithm, but I
want to see Mathias' code before falling back on mine. Mine worked
well for DOS, but better anti-aliasing is expected nowadays.)

DrawTree takes an existing ScreenPainter so I can limit it's scope
to only where it's used. The new reference counting under the hood
means that while the struct is copied several times here, it isn't
wasteful.

The eventLoop inline delegate allows you to close the window by
pressing any key as well as using the button in the corner. I
don't think the Python version on rosetta code would allow this.


Comparing to the Python version, mine is a little shorter, primarily
due to the much simpler initialization. The Python one took three
lines to do what SimpleWindow's constructor does in one. I also
put the "get_surface" kind of thing that allows drawing inline
to the drawTree line. Like I said above, this was for reasons of
scope, but it coincidentally shaves a line too. As does the struct
destructor doing the job of display.flip().

The last place where I save a couple lines is the event loop, doing
all that in one place instead of a separate function, loop, and
fetcher. (Note: the delegate in there is not strictly necessary!
It handles quit events sanely by default.)


All in all, I'm very happy with this approach so far. It's simple,
it's short, it's readable, it's reasonably efficient, and the
implementation is moderately lean. Everything I was hoping for!
Apr 09 2011
next sibling parent Matthias Pleh <jens konrad.net> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Am 10.04.2011 04:30, schrieb Adam D. Ruppe:

 bearophile wrote:

 More little tasks for your module:
 http://rosettacode.org/wiki/Fractal_tree#Python



 This one's use of recursion caused me to hit what I think is a
 compiler bug. Not in the recursion itself, but in a struct's
 copy constructor when it had a significant mixin.

 I worked around it by declaring a private struct and using a pointer
 to it rather than mixing in the implementation directly. I believe
 this will be a net-positive too, since ScreenPainter is now
 referenced counted.

 Here's the implementation:

 ====
 import simpledisplay;
 import std.math;

 void main() {
      // auto image = new Image(600, 600);
      auto window = new SimpleWindow(600, 600, "Fractal Tree");

      void drawTree(ScreenPainter p, in int x1, in int y1, in real angle, in int
 depth) {
          if(depth == 0)
              return;
          immutable x2 = x1 + cast(int) (cos(angle) * depth * 10);
          immutable y2 = y1 + cast(int) (sin(angle) * depth * 10);
          p.drawLine(Point(x1, y1), Point(x2, y2));

          drawTree(p, x2, y2, angle - 0.35, depth - 1);
          drawTree(p, x2, y2, angle + 0.35, depth - 1);
      }

      drawTree(window.draw, 300, 550, -PI / 2, 9);
      window.eventLoop(0, (dchar) { window.close(); });
      // displayImage(image);
 }

 ===

 The reason Image is there, but commented out, is that such things
 might be better done as images, then displayed once finished.
 But, since we don't have drawing lines to images yet*, I went
 direct to screen instead.

 (well, I do have my implementation of Bresenham's algorithm, but I
 want to see Mathias' code before falling back on mine. Mine worked
 well for DOS, but better anti-aliasing is expected nowadays.)

 DrawTree takes an existing ScreenPainter so I can limit it's scope
 to only where it's used. The new reference counting under the hood
 means that while the struct is copied several times here, it isn't
 wasteful.

 The eventLoop inline delegate allows you to close the window by
 pressing any key as well as using the button in the corner. I
 don't think the Python version on rosetta code would allow this.


 Comparing to the Python version, mine is a little shorter, primarily
 due to the much simpler initialization. The Python one took three
 lines to do what SimpleWindow's constructor does in one. I also
 put the "get_surface" kind of thing that allows drawing inline
 to the drawTree line. Like I said above, this was for reasons of
 scope, but it coincidentally shaves a line too. As does the struct
 destructor doing the job of display.flip().

 The last place where I save a couple lines is the event loop, doing
 all that in one place instead of a separate function, loop, and
 fetcher. (Note: the delegate in there is not strictly necessary!
 It handles quit events sanely by default.)


 All in all, I'm very happy with this approach so far. It's simple,
 it's short, it's readable, it's reasonably efficient, and the
 implementation is moderately lean. Everything I was hoping for!




Ok, this is what I have so far.
It's code, I have written one year ago and is based on AntiGrain , which 
is based on freetype2, which is based on libart?
AntiGrain is under the modified BSD-license.
To prevent license-issues(if it should go into phobos) and to get a
faster version, I'v started form scratch, but this is not finished yet.
But you can get an idea, how it should work.


 (well, I do have my implementation of Bresenham's algorithm, but ..



simple lines, I think Bresenham's algorithm (also anti-aliased) will 
maybe faster (fewer overhead), but for thicker lines with different 
caps, you need polygons anyway, so ...

In the test.d file is an example, which produce the image (.ppm) I have 
posted.
(note, you need the Color struct form simpledisplay.d)

have fun,

°Matthias
Apr 09 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 I believe so, yes, but I haven't tried it and wouldn't mind if
 it didn't. If you need to use multiple windows at the same time,
 it'd probably be better to use DFL, DWT, GTK, Qt, etc. etc.



It's better to support multiple windows, otherwise you have to split the single
window "manually" if you want a window with a simulation and a window with a
graph about the simulation.



 Heh, I used to call it box in my DOS programs. But, the functions
 it forwards to are called Rectangle() and XDrawRectangle(), so
 I want to be consistent with them so it's not a surprise to
 someone already familiar with with the other APIs.



I don't agree. line(), box(), circle(), etc are so easy to remember and common
that I don't see the need to keep the names of the functions under them.

 

 The reason I went with drawShape instead of just Shape is that
 functions are verbs, so generally, I like their names to be
 verbs too. There's exceptions, of course, but I don't these
 fit.



I don't agree. It's _very_ easy to understand that p.line() is to add a line,
there is no chance of confusion here, the verb of p.drawLine() is implied.



 But, here, the idea was to keep it simple, so I went with just
 color. I guess that might be too simple.



In this module shaded pens are less important than usage simplicity. I suggest
to keep things simple here.



 A note: since I posted last, I changed my mind on something, and
 bearophile, I rather doubt you'll like it...



I think it's acceptable :-)

----------------------------


 This one's use of recursion caused me to hit what I think is a
 compiler bug. Not in the recursion itself, but in a struct's
 copy constructor when it had a significant mixin.



Where is the updated display module?
This doesn't seem to be updated yet:
http://arsdnet.net/dcode/simpledisplay.d

In your little program drawTree() is better "static" (or better, moved out of
the main).


window.eventLoop(0, (dchar){ window.close(); });
==> Default arguments?
window.eventLoop();



 Comparing to the Python version, mine is a little shorter,



PyGame is also quite more powerful than your simpledisplay module, you can
write small video games with it. So its API is a little more complex.

 

 All in all, I'm very happy with this approach so far. It's simple,
 it's short, it's readable, it's reasonably efficient, and the
 implementation is moderately lean. Everything I was hoping for!



Before freezing the API design I suggest to implement many more quite different
examples. Designing APIs is something that can't be done in a hurry :-)

Two features are quite important:

Mouse position, mouse clicks, keys pressed:
http://processingjs.org/learning/topic/pattern

Text:
http://processingjs.org/learning/topic/tickle

---------------

Few more useful features for later:

Transparency:
http://processingjs.org/learning/topic/follow2

Antialiasing:
http://processing.org/learning/topics/penrosetile.html

Polygons, curves:
http://processing.org/learning/topics/softbody.html

Image loading:
http://processingjs.org/learning/topic/blur

Save screen:
http://processing.org/learning/topics/saveoneimage.html

Sprites:
http://processing.org/learning/topics/unlimitedsprites.html

Bye,
bearophile
Apr 10 2011
prev sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
--00032555f6c6d5149504a093aa63
Content-Type: text/plain; charset=ISO-8859-1


 Heh, I used to call it box in my DOS programs. But, the functions
 it forwards to are called Rectangle() and XDrawRectangle(), so
 I want to be consistent with them so it's not a surprise to
 someone already familiar with with the other APIs.



 I don't agree. line(), box(), circle(), etc are so easy to remember and
 common that I don't see the need to keep the names of the functions under
 them.



 The reason I went with drawShape instead of just Shape is that
 functions are verbs, so generally, I like their names to be
 verbs too. There's exceptions, of course, but I don't these
 fit.



 I don't agree. It's _very_ easy to understand that p.line() is to add a
 line, there is no chance of confusion here, the verb of p.drawLine() is
 implied.



design (it just strikes me as weird all around actually.)  If this were
retained mode, something like p.Add(Line(...)) would make sense.  But if the
action is to draw a line, and the target of that action is object p, then
p.drawLine is the most sensible.  The objective here is not to relieve the
user of typing, but to ensure the code is unambiguously clear.  Imagine
p.box. What does that mean?  Draw a box?  Or are we boxing p into some
portable format?  I agree with Adam's original thought that methods should
be verbs.  At least to my mind is reads easier.  YMMV.

- Cliff

--00032555f6c6d5149504a093aa63
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=
=3D"im">
&gt; Heh, I used to call it box in my DOS programs. But, the functions<br>
&gt; it forwards to are called Rectangle() and XDrawRectangle(), so<br>
&gt; I want to be consistent with them so it&#39;s not a surprise to<br>
&gt; someone already familiar with with the other APIs.<br>
<br>
</div>I don&#39;t agree. line(), box(), circle(), etc are so easy to rememb=
er and common that I don&#39;t see the need to keep the names of the functi=
ons under them.<br>
<div class=3D"im"><br>
<br>
&gt; The reason I went with drawShape instead of just Shape is that<br>
&gt; functions are verbs, so generally, I like their names to be<br>
&gt; verbs too. There&#39;s exceptions, of course, but I don&#39;t these<br=



<br>
</div>I don&#39;t agree. It&#39;s _very_ easy to understand that p.line() i=
s to add a line, there is no chance of confusion here, the verb of p.drawLi=
ne() is implied.<br>
<div class=3D"im"><br></div></blockquote><div>=A0</div><div>I would argue t=
hat p.line is inconsistent with an immediate-mode drawing API design (it ju=
st strikes me as weird all around actually.) =A0If this were retained mode,=
 something like p.Add(Line(...)) would make sense. =A0But if the action is =
to draw a line, and the target of that action is object p, then p.drawLine =
is the most sensible. =A0The objective here is not to relieve the user of t=
yping, but to ensure the code is unambiguously clear. =A0Imagine p.box. Wha=
t does that mean? =A0Draw a box? =A0Or are we boxing p into some portable f=
ormat? =A0I agree with Adam&#39;s original thought that methods should be v=
erbs. =A0At least to my mind is reads easier. =A0YMMV.</div>
<div><br></div><div>- Cliff</div></div>

--00032555f6c6d5149504a093aa63--



 Apr 10 2011