www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - simpledisplay.d now works on as 64 bit on X

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I know someone here was asking about my simpledisplay.d on 64 bit 
a while ago.. I don't remember who so here's a general 
announcement.

I got it working for at least the parts I tried (display image, 
get keyboard input) compiled with -m64:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d

Quite a hassle, my xlib binding was apparently almost completely 
wrong, and it worked on 32 bit just by sheer luck. Many of the 
structs were the wrong sizes even there! General tip to C 
porters: do a static assert(S.sizeof) and make sure it matches 
what your C program gives. I got snagged in part here because 
unsigned long in X is apparently 64 bit. I thought it was the 
same as D's uint in all cases.

The file it also depends on color.d from the same repo. Another 
minor change is the key event used to take a delegate (int 
key){}. Now it takes (int key, bool pressed) instead. There's a 
static assert with a reminder message too, so just compile and if 
you need it, it will tell you. The (dchar){} event remains the 
same as before.

Been a few random bug fixes in the last few months too, timer 
events now work right on windows and linux is the big one that 
comes to mind.
Jun 02 2013
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
I'm sorry to hear that you ran into the unsigned long problem.
I noticed it in time and asked about it on the NG and was told
that the difference is between Windows and Posix. One takes
long as int32, the other as the native machine word size on
64-bit. We do the same stupid mistakes over and over. :p

Also eventually we should generate X bindings for all
platforms (including Windows) from the XML definitions like
XCB does. That means a small core written in D that enables
RPC to the X Server and a generator tool that creates
functions, structs and DDoc from what is the XML files.
(See /usr/share/xcb.)

-- 
Marco
Jun 02 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/2/13, Marco Leise <Marco.Leise gmx.de> wrote:

 I'm sorry to hear that you ran into the unsigned long problem.


This is why we have core.std.config:

import core.stdc.config : c_long, c_ulong;
Jun 02 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 22:16:57 UTC, Andrej Mitrovic wrote:

 This is why we have core.std.config:

 import core.stdc.config : c_long, c_ulong;


I would never have thought to look in "config" for types! Well, 
hopefully I'll remember for next time.
Jun 02 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 This is why we have core.std.config:

 import core.stdc.config : c_long, c_ulong;


Why isn't that linked in this page?
http://dlang.org/phobos/std_stdint.html

I'd like to open a little documentation enhancement request for 
that.

Bye,
bearophile
Jun 02 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/2/13 7:10 PM, bearophile wrote:

 Andrej Mitrovic:


 This is why we have core.std.config:

 import core.stdc.config : c_long, c_ulong;


 Why isn't that linked in this page?
 http://dlang.org/phobos/std_stdint.html

 I'd like to open a little documentation enhancement request for that.

 Bye,
 bearophile


And while you are at it, please also contribute the corresponding pull 
request. Time to inaugurate bearophile's additions!

Andrei
Jun 02 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 And while you are at it, please also contribute the 
 corresponding pull request. Time to inaugurate bearophile's 
 additions!


As my friend, please understand, I can't afford to get addicted 
to that :-)

Hugs,
bearophile
Jun 02 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 Why isn't that linked in this page?
 http://dlang.org/phobos/std_stdint.html


It seems it lacks some of them, this gives an import error:

import core.stdc.config: c_ulonglong, c_longlong;

Bye,
bearophile
Jun 02 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 23:19:18 UTC, bearophile wrote:

 It seems it lacks some of them, this gives an import error:


It only defines c_long and c_ulong. I guess this is ok because 
the other types don't vary, though I kinda think it should do 
them all just so you can be consistent.

Not long ago I thought int on 64 bit was 64 bit too, because int 
on 16 bit is 16 bit so I figured it just did that the whole way 
up. But no, C's int is always D's int.

A nice c_int alias would make that mindless too, even though it 
isn't strictly necessary.
Jun 02 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/3/13, bearophile <bearophileHUGS lycos.com> wrote:

 Why isn't that linked in this page?
 http://dlang.org/phobos/std_stdint.html


Because it's on this page:

http://dlang.org/interfaceToC.html


 It seems it lacks some of them, this gives an import error:
 import core.stdc.config: c_ulonglong, c_longlong;


Again see http://dlang.org/interfaceToC.html
Jun 02 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote:

 http://dlang.org/interfaceToC.html


aaaaah then what is this page doing there?
http://dlang.org/htomodule.html

The documentation could def use a lil cleanup.
Jun 02 2013
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/3/13, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote:

 http://dlang.org/interfaceToC.html


 aaaaah then what is this page doing there?
 http://dlang.org/htomodule.html

 The documentation could def use a lil cleanup.


There's a bug report for everything:
http://d.puremagic.com/issues/show_bug.cgi?id=7346

I'm like a handy little bugzilla bot. :p
Jun 02 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 Because it's on this page:

 http://dlang.org/interfaceToC.html


 It seems it lacks some of them, this gives an import error:
 import core.stdc.config: c_ulonglong, c_longlong;


 Again see http://dlang.org/interfaceToC.html


Good, thank you. I missed that.

Bye,
bearophile
Jun 02 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote:

 Also eventually we should generate X bindings for all
 platforms (including Windows) from the XML definitions like
 XCB does.


hmm I don't see an xml file for Xlib.h on my system, do you know 
if there is supposed to be one? Though I'm pretty sure I have 
most of it correct now, so I guess it isn't really necessary.

I know everybody says Xlib is dying but I still use it. It is 
simple enough and gets the job done without having to learn a 
whole thing library...
Jun 02 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 03 Jun 2013 01:02:12 +0200
schrieb "Adam D. Ruppe" <destructionator gmail.com>:


 On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote:

 Also eventually we should generate X bindings for all
 platforms (including Windows) from the XML definitions like
 XCB does.


 
 hmm I don't see an xml file for Xlib.h on my system, do you know 
 if there is supposed to be one? Though I'm pretty sure I have 
 most of it correct now, so I guess it isn't really necessary.


XCB is generated from these XML files. They have nothing to do
with Xlib. You can find the XML files here:
http://cgit.freedesktop.org/xcb/proto/tree/src
A generator tool for the target language (C in this case)
parses them and creates include files from them that define
all the remote procedure calls to the X Server. Internally
those calls rely on a small generic set of functions that
serializes the requests for transmission.

What is needed are those generic functions written in D to
establish the connection to the server and handling
serialization, probably relying on std.socket.
And then an XML parser that would write out .d files for the
different modules of the X Server, like xrandr, xkb and so on,
which are all available as separate XML files.

This is what a RPC from glx.xml looks like:

	<request name="GenTextures" opcode="145">
		<field type="CONTEXT_TAG" name="context_tag" />
		<field type="INT32" name="n" />
		<reply>
			<pad bytes="1" />
			<pad bytes="24" />
			<list type="CARD32" name="data">
				<fieldref>length</fieldref>
			</list>
		</reply>
	</request>

In general they also include documentation tags which can be
made available through DDoc automatically and displayed in
IDEs like Mono-D already does.


 I know everybody says Xlib is dying but I still use it. It is 
 simple enough and gets the job done without having to learn a 
 whole thing library...


The big deal about it is asynchronous RCP especially over
internet connections to X Servers, since with Xlib you have to
way for each response before the next request.

-- 
Marco
Jun 02 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote:

 all the remote procedure calls to the X Server. Internally
 those calls rely on a small generic set of functions that
 serializes the requests for transmission.


I see. I just skimmed an xcb tutorial and it isn't all that 
different than xlib so maybe I'll spend a weekend on it at some 
point and make it work in D.

There's a few things we can do to make the async stuff pretty 
too, thanks to delegates and the sort.

And perhaps I can add a concept of a sprite to simplediplay. This 
represents an XPixmap - distinct from an XImage in that it is on 
the server - or on Windows, we can probably just us an HBITMAP. 
These wouldn't offer direct pixel manipulation like 
simplediplay's current Image (which is an XImage and HBITMAP in 
implementation) but would be able to avoid transferring a lot of 
data to the X server.

And lastly (optionally, like with terminal.d) tie it into my 
generic eventloop.d. Then we'll really be cooking with gas! It'll 
have to wait a while though, hacking on this stuff doesn't make 
my house payments :(
Jun 02 2013
parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 3 June 2013 at 01:31:27 UTC, Adam D. Ruppe wrote:

 On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote:

 all the remote procedure calls to the X Server. Internally
 those calls rely on a small generic set of functions that
 serializes the requests for transmission.


 I see. I just skimmed an xcb tutorial and it isn't all that 
 different than xlib so maybe I'll spend a weekend on it at some 
 point and make it work in D.

 There's a few things we can do to make the async stuff pretty 
 too, thanks to delegates and the sort.

 And perhaps I can add a concept of a sprite to simplediplay. 
 This represents an XPixmap - distinct from an XImage in that it 
 is on the server - or on Windows, we can probably just us an 
 HBITMAP. These wouldn't offer direct pixel manipulation like 
 simplediplay's current Image (which is an XImage and HBITMAP in 
 implementation) but would be able to avoid transferring a lot 
 of data to the X server.

 And lastly (optionally, like with terminal.d) tie it into my 
 generic eventloop.d. Then we'll really be cooking with gas! 
 It'll have to wait a while though, hacking on this stuff 
 doesn't make my house payments :(


There is already a functional XCB binding somewhere on GitHub. I 
managed to compiled it and play with it last year with success.
Jun 05 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 5 June 2013 at 16:33:57 UTC, Dejan Lekic wrote:

 There is already a functional XCB binding somewhere on GitHub. 
 I managed to compiled it and play with it last year with 
 success.


cool... I found one on dsource but not github yet. The dsource 
one transforms the XML but doesn't seem to implement all needed 
functions. Shouldn't be hard to complete anyway though.

This is kinda exciting. I gotta say, part of me wants to write an 
X /server/ now too. How hard can it be? Run the protocol 
generator in reverse if you will and implement the functions I 
want. Why? Cuz then I'll add extensions I want to play with 
easily and ultimately compile it to javascript :P
Jun 05 2013
next sibling parent reply "maarten" <maartenvd1994 gmail.com> writes:
Very good news that I can now compile it on my 64 bit machine,
because dmd not only refused to in the past but I couldn't even
get -m32 working. (Probably installed something somewhere
incorrectly?)

Thank you :)
Jun 08 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 8 June 2013 at 22:45:36 UTC, maarten wrote:

 Very good news that I can now compile it on my 64 bit machine,
 because dmd not only refused to in the past but I couldn't even
 get -m32 working. (Probably installed something somewhere
 incorrectly?)


It should pretty much just work if you just grab simpledisplay.d 
and color.d and add both files to your dmd command to compile all 
at once.

If not though let me know and I can look into it.
Jun 09 2013
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 06 Jun 2013 01:27:58 +0200
schrieb "Adam D. Ruppe" <destructionator gmail.com>:


 cool... I found one on dsource but not github yet. The dsource 
 one transforms the XML but doesn't seem to implement all needed 
 functions. Shouldn't be hard to complete anyway though.


Does that mirror XCB (independent of XCB, implements RPC) or
add a wrapper layer around the C bindings? Because it would be
kinda cool to have a real X sever binding in D and not just
D bindings to the C bindings to the X server. :p

-- 
Marco
Jun 08 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 05:53:40 UTC, Marco Leise wrote:

 Does that mirror XCB (independent of XCB, implements RPC) or
 add a wrapper layer around the C bindings? Because it would be
 kinda cool to have a real X sever binding in D and not just
 D bindings to the C bindings to the X server. :p


It is just bindings right not but it is built from the xml file 
so if I spent some time tweaking it and writing the 10 or so base 
functions it needs from the C library it should be good to go.

Though tweaking it is harder for me than it should be because I 
don't know xslt at all. I might just do my own thing anyway, I'm 
reading up on the x protocol myself so I know all the needed 
details.
Jun 09 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d


Time ago I tried simpledisplay (on 32 bit Windows) and I remember 
I had to make the class Image final to have some performance. I 
used it on Rosettacode too:

http://rosettacode.org/wiki/Forest_fire#Graphical_Version


I have tried that Forest fire code with your new version and it 
gives me a:
simpledisplay.d(676): Error: undefined identifier i, did you mean 
variable s?

The line is here:

void drawPixmap(Sprite s, int x, int y) {
     BITMAP bm;

     HDC hdcMem = CreateCompatibleDC(hdc);
     HBITMAP hbmOld = SelectObject(hdcMem, s.handle);

     GetObject(i.handle, bm.sizeof, &bm); <<


Bye,
bearophile
Jun 09 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 12:09:03 UTC, bearophile wrote:

 Time ago I tried simpledisplay (on 32 bit Windows) and I 
 remember I had to make the class Image final to have some 
 performance. I used it on Rosettacode too:


Hmm probably putPixel and impl.putPixel is too slow, it is called 
a lot. I made the class final now and got a about 8% improvement, 
using linux right now.

Eliminating those calls entirely, writing straight to the private 
rawData pointer, gives about 12% improvement, since this would 
get rid of calculating pixel offsets too (we can just do ptr++). 
Maybe I'll expose that and try to make it somehow cross platform.

I got as high as 45 fps using that trick plus the dmd -inline 
-release -O -noboundscheck flags. (The original code without 
flags and without final gave me only 30 fps).

I compiled and ran on wine too and it seems to have worked. 
Here's the nextState function using a pointer:


void nextState(ref World world, ref World nextWorld,
                ref Xorshift rnd, Image img) {
   auto pixelPointer = img.getDataPointer();
   auto linePadding = img.bytesPerLine() - img.bytesPerPixel * 
img.width;
   auto pixelPadding = img.bytesPerPixel() - 3;
   enum double div = cast(double)typeof(rnd.front()).max;
   immutable nr = world.length;
   immutable nc = world[0].length;
   foreach (r, row; world) {
     foreach (c, elem; row) {
       final switch (elem) {
         case Cell.empty:
		*pixelPointer++ = 255;
		*pixelPointer++ = 255;
		*pixelPointer++ = 255;
           //img.putPixel(c, r, white);
           nextWorld[r][c] = (rnd.front()/div)<P_PROB ? Cell.tree 
: Cell.empty;
           rnd.popFront();
           break;

         case Cell.tree:
           //img.putPixel(c, r, green);
	  	*pixelPointer++ = 0;
	  	*pixelPointer++ = 255;
	  	*pixelPointer++ = 0;

           foreach (rowShift; sp)
             foreach (colShift; sp)
               if ((r + rowShift) >= 0 && (r + rowShift) < nr &&
                   (c + colShift) >= 0 && (c + colShift) < nc &&
                   world[r + rowShift][c + colShift] == 
Cell.burning) {
                 nextWorld[r][c] = Cell.burning;
                 goto END;
               }

           nextWorld[r][c]=(rnd.front()/div)<F_PROB ? Cell.burning 
: Cell.tree;
           rnd.popFront();
           END: break;

         case Cell.burning:
           //img.putPixel(c, r, red);
	  	*pixelPointer++ = 0;
	  	*pixelPointer++ = 0;
	  	*pixelPointer++ = 255;
           nextWorld[r][c] = Cell.empty;
           break;
       }

       pixelPointer += pixelPadding;
     }

     pixelPointer += linePadding;
   }

   swap(world, nextWorld);
}



 I have tried that Forest fire code with your new version and it 
 gives me a:
 simpledisplay.d(676): Error: undefined identifier i, did you 
 mean variable s?


oops fixed. I added a new function but didn't even compile the 
Windows version of this change (only tried linux) and made a typo 
there.
Jun 09 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 I got as high as 45 fps using that trick plus the dmd -inline 
 -release -O -noboundscheck flags. (The original code without 
 flags and without final gave me only 30 fps).




seems to be more than 10 times slower than D entry (the image 
says 2.9 FPS, but maybe it's in debug mode):
http://rosettacode.org/wiki/Forest_fire#F.23



 I compiled and ran on wine too and it seems to have worked.


thank you for your quick fixes and improvements :-)



 oops fixed.


After this you will probably be more careful in future, to avoid 
similar bugs :-)

Bye and thank you,
bearophile
Jun 09 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 14:00:20 UTC, bearophile wrote:


 slower than D entry (the image says 2.9 FPS, but maybe it's in 
 debug mode):


They could have ran it on a slow computer too, only way to be 
fair with these kind of comparisons is to it yourself.


 After this you will probably be more careful in future, to 
 avoid similar bugs :-)


Yeah, I just made a new script on my linux computer called dmdw 
that calls the Windows version of dmd (through wine) for easy 
testing. Now I don't have to get out my laptop just to make sure 
changes still compile.
Jun 09 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 I got as high as 45 fps using that trick plus the dmd -inline 
 -release -O -noboundscheck flags. (The original code without 
 flags and without final gave me only 30 fps).


Compiled with dmd, on my slower PC I see about 37 fps on the 
original code. Using ldc2 on the same code I see 53 fps. Using 
the pointers with ldc2 I see 68 fps.

And with a bit more cache-friendly data structure:
alias World = Cell[worldSide][];
I see 74 fps with ldc2 with pointers.

On Windows Vista the the window close X button on the top right 
doesn't work, and I have to use the close from the window menu on 
the top left.

Bye,
bearophile
Jun 09 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 20:22:24 UTC, bearophile wrote:

 Using the pointers with ldc2 I see 68 fps.


Good speed there. Another problem I just realized though: on 
Windows, bitmaps are stored upside down so you'd have to draw 
y-inverted too. Didn't make a difference here because the image 
doesn't care about orientation but it would be visible with a lot 
of other programs.

Maybe simple functions or mixins (if inlining isn't reliable) 
could be used to hide this detail. Though for max performance you 
might have to know some platform specific details anyway. (and 
this library isn't really made for max performance, instead 
preferring simplicity of use and implementation. but still no 
need to be pointlessly slow)


 On Windows Vista the the window close X button on the top right 
 doesn't work, and I have to use the close from the window menu 
 on the top left.


OK I'll check that from my laptop tomorrow.
Jun 09 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Another problem I just realized though: on Windows, bitmaps are 
 stored upside down so you'd have to draw y-inverted too. Didn't 
 make a difference here because the image doesn't care about 
 orientation but it would be visible with a lot of other 
 programs.

 Maybe simple functions or mixins (if inlining isn't reliable) 
 could be used to hide this detail.


This high level library should generate the same image output on 
all systems it compiles on.



 (and this library isn't really made for max performance, 
 instead preferring simplicity of use and implementation.


A small, basic and simple to use graphics library has its usages. 
For small single-module (or few modules) programs like the one I 
have linked in Rosettacode you don't want to import a large GUI 
library.

Eventually I think such simple simpledisplay.d and color.d 
modules should go in Phobos, after some cleaning, ddoc string, a 
heavy cycle of review and improvements, API design, etc. It's a 
battery worth putting in the standard library. So people can 
write portable and very easy to use little graphical programs in 
D.

Delphi has a large and efficient GUI toolkit in the standard 
library, but I think it's not a good idea to put a GUI toolkit in 
Phobos. But a little library as simpledisplay is OK.

Maybe for Phobos simpledisplay.d could be renamed just 
graphicdisplay.d or something like that.

Regarding color, I think it will enjoy few more color-related 
functions, like a function to generate a rainbow given the 
temperature of a black body, few more greying functions, a bit 
more colorimetry, etc.

A color.d module for Phobos should not import simpledisplay.d. 
And it should be a top-level module (unlike now, that's inside a 
package).

Even the Python standard library has a very minimal color module:
http://docs.python.org/2/library/colorsys.html

A third small module (less than 15-30 KB of code) worth adding to 
Phobos, that builds on graphicdisplay.d and color.d, could 
generate basic data plots (scatter plots and line plots). It's 
not meant to replace a complete library for graphing. It's meant 
for a quick and very simple display of all kind of data during 
development or for quick D script-like programs.

When I program in Python I often use the good 
http://matplotlib.org/ . It's a large plotting library that 
allows me to plot data with few lines of code. This allows me to 
visualize intermediate data during debugging, like arrays, so it 
improves my understanding of data and such data.

Bye,
bearophile
Jun 09 2013
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 10.06.2013 00:09, bearophile pisze:

 Delphi has a large and efficient GUI toolkit in the standard library,
 but I think it's not a good idea to put a GUI toolkit in Phobos. But a
 little library as simpledisplay is OK.


Hmm... What if Lazarus GUI code and/or LCL could be ported to D? I've 
seen full featured Object Pascal parser in their repository. Maybe it's 
possible to transcode the source to D ;) Just thinking loud.
Jun 09 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Piotr Szturmaj:


 Hmm... What if Lazarus GUI code and/or LCL could be ported to 
 D? I've seen full featured Object Pascal parser in their 
 repository. Maybe it's possible to transcode the source to D ;) 
 Just thinking loud.


Even if that's possible, I think it's not a good idea to put the 
resulting large library in Phobos, because everyone has different 
needs and tastes regarding GUI toolkits.

Bye,
bearophile
Jun 09 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 10.06.2013 00:29, bearophile pisze:

 Piotr Szturmaj:


 Hmm... What if Lazarus GUI code and/or LCL could be ported to D? I've
 seen full featured Object Pascal parser in their repository. Maybe
 it's possible to transcode the source to D ;) Just thinking loud.


 Even if that's possible, I think it's not a good idea to put the
 resulting large library in Phobos, because everyone has different needs
 and tastes regarding GUI toolkits.


Yes, I was just suggesting to not write such library from scratch.
Jun 09 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 22:09:55 UTC, bearophile wrote:

 This high level library should generate the same image output 
 on all systems it compiles on.


Naturally. But if we can get a 10% performance boost that can be 
worth it in a lot of cases. Maybe the api can actually be an 
output range for colors that does one pixel at a time from top to 
bottom, left to right. That'd be less raw than the pointer but 
still avoid recalculating offsets every time when it could just 
be a simple increment.


 A small, basic and simple to use graphics library has its 
 usages. For small single-module (or few modules) programs like 
 the one I have linked in Rosettacode you don't want to import a 
 large GUI library.


Yes, I agree. I used to do a lot of fun stuff in DOS back in the 
day when all you have is a 256 color, 320x200 framebuffer. It was 
great actually, much lower learning curve than today's huge GUIs 
and capable of all the fun stuff. That's why I made 
simpledisplay.d and terminal.d, an attempt to get that kind of 
thing easy again on new operating systems.

There's libraries like SDL that are fairly simple and quite 
useful too but that is much bigger.


 Eventually I think such simple simpledisplay.d and color.d 
 modules should go in Phobos


That's something I'm not really interested in though, because....


 after some cleaning, ddoc string, a heavy cycle of review and 
 improvements, API design, etc.


that is starting to sound like work! I hack together most these 
modules over weekends, and even if I can spill onto weekdays it 
is still just getting it to barely work for me then time to move 
on.


 Regarding color, I think it will enjoy few more color-related 
 functions, like a function to generate a rainbow given the 
 temperature of a black body, few more greying functions, a bit 
 more colorimetry, etc.


Yeah, those would be cool. I think I have blackbody code 
somewhere, I wrote it for one of my games. My lazypng.d module 
also has a greyscale thing - the plan there was to do png files 
to and from ranges, and add various algorithm like things to 
operate on them.

The png reader in there is actually more complete than the one in 
my png.d, but png.d includes nice helper functions for palette 
swaps, creating Windows icons, etc. that lazypng lacks.

anyway I'm getting sidetracked, sometimes I wish I could get 
enough money to pay my bills just for hacking on random D stuff - 
maybe then I could kill this todo list!


 A third small module (less than 15-30 KB of code) worth adding 
 to Phobos, that builds on graphicdisplay.d and color.d, could 
 generate basic data plots (scatter plots and line plots).


What might be better is to do it on top of something like a 
simple image class, which can then be drawn to the screen or 
saved to a file.

A downside though is a lot of graphics functions would have to be 
written, but I think I want to do that anyway eventually. I 
wouldn't do a great job, like most my modules I'd just hack it 
together over a weekend, but it'd be a start. I already have an 
image.d that can be saved to a file.
Jun 09 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/9/13, Adam D. Ruppe <destructionator gmail.com> wrote:

 on Windows, bitmaps are stored upside down so you'd have to draw
 y-inverted too.


I have some vague memory about a trick where using a negative height
would flip the bitmap automatically. (something like that .. maybe
wrong, worth trying though?)
Jun 09 2013