Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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). Some people keep saying how much nice the F# language is, and indeed I like it and it's nice. But on that page the F# entry 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
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
On Sunday, 9 June 2013 at 14:00:20 UTC, bearophile wrote: But on that page the F# entry seems to be more than 10 times 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.
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
On 6/9/13, Adam D. Ruppe destructiona...@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?)
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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 :)
Re: simpledisplay.d now works on as 64 bit on X
Am Thu, 06 Jun 2013 01:27:58 +0200 schrieb Adam D. Ruppe destructiona...@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
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
On 6/2/13, Marco Leise marco.le...@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;
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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...
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
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.
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
On 6/3/13, bearophile bearophileh...@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
Re: simpledisplay.d now works on as 64 bit on X
On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote: http://dlang.org/interfaceToC.html ah then what is this page doing there? http://dlang.org/htomodule.html The documentation could def use a lil cleanup.
Re: simpledisplay.d now works on as 64 bit on X
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
Re: simpledisplay.d now works on as 64 bit on X
On 6/3/13, Adam D. Ruppe destructiona...@gmail.com wrote: On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote: http://dlang.org/interfaceToC.html ah 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
Re: simpledisplay.d now works on as 64 bit on X
Am Mon, 03 Jun 2013 01:02:12 +0200 schrieb Adam D. Ruppe destructiona...@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 fieldreflength/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
Re: simpledisplay.d now works on as 64 bit on X
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 :(
