On 2011-04-08 20:11:10 -0400, Adam D. Ruppe <destructionator@gmail.com> said:

> My only concern is I don't want Phobos to depend on Xlib unless
> the module is actually imported. I don't think it will be a problem,
> but if it means a hello world won't run on a text only machine, that
> won't be ok.

I'm concerned by this too.

I think you need two modules. One for images images with absolutely no dependencies, and another for everything dealing with windows. Only if you import the window module you need to link with the relevant libraries.

That means you'll need to change the image.display() shortcut to something else not a member of image. I don't think it's particularly good that images has such a member anyway, it'd be better as a standalone function in my opinion.

(Actually, perhaps we need a third to deal with drawing which might also be dependent on system libraries, especially if needs to draw text.)

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-04-08 20:18:03 -0400, Adam D. Ruppe <destructionator@gmail.com> said:

> dsimcha wrote:
>> Can it render text?
> 
> Not yet, but it's on the list. Anything that's reasonably easy
> in both Windows API and Xlib should be supported here. At the least,
> text, lines, rectangles - all the basics.

One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different images, which might introduce glitches from platform to platform. I wonder if it might not be better to implement our own drawing algorithms for geometric shapes, which in addition won't be dependent on any system library.

I guess text drawing would need to be left system-dependent however...


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Text drawing is as simple as TextDraw or TextOut on Windows. Dunno about the nixes.

Michel Fortin wrote:
> One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different
>images, which might introduce glitches from platform to platform.

I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client).

So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.)


What this means is if we want to draw to images, we've
got to spin our own algorithms. Which makes the different OS
algorithms moot - the direct screen drawing will be different, but
the images will all be the same. The downside is their functions
will lag a bit since I can't just wrap some C calls.

Andrej Mitrovic wrote:
> Text drawing is as simple as TextDraw or TextOut on Windows. Dunno about the nixes.

It's XDrawString() - almost the same.

Text output is now implemented on my local copy of the module for both systems.

It looks like SDL (1.3) will be under zlib license soon[1] so maybe
using it or parts of it or whatever may be feasible, even in Phobos -
the zlib license should be "free" enough, it says
"If you use this software in a product, an acknowledgment in the product
documentation would be appreciated but is not required."
so there's no binary attribution clause.

Cheers,
- Daniel

[1] http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526

On 2011-04-08 21:45:20 -0400, Adam D. Ruppe <destructionator@gmail.com> said:

> Michel Fortin wrote:
>> One issue is that different operating system will draw things with
>> slightly different algorithms, which will result in slightly different
>> images, which might introduce glitches from platform to platform.
> 
> I actually hit an even bigger problem... Xlib can't actually draw
> to XImages, and you don't have direct pixel access to XPixmaps
> (it's the difference between being on the X Server and the client).
> 
> So, the lowest common denominator, using only system libraries, is
> actually to allow *only* pixel access to Image, and move other
> drawing over to the Window. (Specifically, a Painter struct that
> ties to the window, so it can manage graphics contexts... yeah,
> it's starting to get complicated again.)
> 
> What this means is if we want to draw to images, we've
> got to spin our own algorithms. Which makes the different OS
> algorithms moot - the direct screen drawing will be different, but
> the images will all be the same. The downside is their functions
> will lag a bit since I can't just wrap some C calls.

Personally, I wouldn't even bother with direct screen drawing in that case. Direct screen drawing will need a different implementation for each OS, which means a lot of duplicated effort that could be put in implementing dependency-less cross-platform drawing primitives instead.

As for text, which library does the X server uses to draw text? Freetype? You could link directly to it when you need to draw text... and on other OS use similar OS services.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:
> Direct screen drawing will need a different implementation for
> each OS, which means a lot of duplicated effort that could be put in
> implementing dependency-less cross-platform drawing primitives
> instead.

I'd agree if not for one thing: it isn't really much duplicated effort - most the functions are just a few lines long; it wraps C. There's a good chance I'll be able to finish them in the next hour for Win32 and X11.

> As for text, which library does the X server uses to draw text?

I think it's freetype for ttf and for bitmap fonts it's built into it. Linking directly to it is a good idea.

Daniel Gibson wrote:
> It looks like SDL (1.3) will be under zlib license soon

Now, that's pretty cool!

Am 09.04.2011 03:55, schrieb Michel Fortin:
> On 2011-04-08 21:45:20 -0400, Adam D. Ruppe <destructionator@gmail.com>
> said:
>
>> Michel Fortin wrote:
>>> One issue is that different operating system will draw things with
>>> slightly different algorithms, which will result in slightly different
>>> images, which might introduce glitches from platform to platform.
>>
>> I actually hit an even bigger problem... Xlib can't actually draw
>> to XImages, and you don't have direct pixel access to XPixmaps
>> (it's the difference between being on the X Server and the client).
>>
>> So, the lowest common denominator, using only system libraries, is
>> actually to allow *only* pixel access to Image, and move other
>> drawing over to the Window. (Specifically, a Painter struct that
>> ties to the window, so it can manage graphics contexts... yeah,
>> it's starting to get complicated again.)
>>
>> What this means is if we want to draw to images, we've
>> got to spin our own algorithms. Which makes the different OS
>> algorithms moot - the direct screen drawing will be different, but
>> the images will all be the same. The downside is their functions
>> will lag a bit since I can't just wrap some C calls.
>
> Personally, I wouldn't even bother with direct screen drawing in that
> case. Direct screen drawing will need a different implementation for
> each OS, which means a lot of duplicated effort that could be put in
> implementing dependency-less cross-platform drawing primitives instead.
>
> As for text, which library does the X server uses to draw text?
> Freetype? You could link directly to it when you need to draw text...
> and on other OS use similar OS services.
>
>

For the drawingt part. I'm currently working on a rednerer with scanline algorithm. This will be completly OS-independent. It's in a single file with 2kLOC, and rather low level drawing. I just render on a simple ubyte-array, but it already support polygon-rendering, antialiasing and different color-structs.

This is how it looks like for now:
http://img683.imageshack.us/i/testawa.jpg/
this takes currently 62ms to render, don't know if this is fast enough,
but can definitley improved.

°Matthias