Best way/library to draw individual pixels on screen? (for fractals)

[Wolfnoliir]

Hello,
I would like to know what library and method you would recommend for
displaying individual pixels on the screen in the scope of producing
representations of fractals based on complex iteration (e.g. Mandelbrot
or Julia). So it is important that the method be speed efficient.
I would also be interested in knowing (very briefly) how one would go
about making a video player inside a GTK application.

I have some knowledge of SDL and OpenGL already.

 

[Seebs]

Hello,
I would like to know what library and method you would recommend for
displaying individual pixels on the screen in the scope of producing
representations of fractals based on complex iteration

Something suitable to my target platform. The answer would be very different
for the iPhone than it would for a Linux desktop...

Which is to say, this has very little to do with C. Try a group related to
the platform.

-s

 

[Ian Collins]

Seebs a écrit :
Thanks but I would prefer something platform independent.

There isn't anything platform independent.

 

[Peter Nilsson]

Something suitable to my target platform.  The answer would
be very different for the iPhone than it would for a Linux
desktop...

I wouldn't recommend it, but as a one off I might run the
following and open the resultant mand.html file on either
platform.

#include <stdio.h>
#include <stdlib.h>

#define T -0.65
#define B -0.75

#define L -0.33
#define R -0.23

#define ROWS 300
#define COLS 300

#define Jre .5
#define Jim -.2

#define MAXITER 1000

#define SZ 1

#define FILENAME "mand.html"

double scale(double a, double b, double c, double v, double w)
{
return v + (a - b) / (c - b) * (w - v);
}

size_t mand(double cre, double cim, size_t max)
{
double re, im;
double nre, nim;
size_t iter;

re = Jre;
im = Jim;
for (iter = 0; iter < max; iter++)
{
nre = re * re - im * im + cre;
nim = 2 * re * im + cim;
re = nre;
im = nim;
if (re * re + im * im >= 4.0) return iter;
}

return iter;
}


int main(void)
{
FILE *fp;
size_t r, c;

fp = fopen(FILENAME, "w");
if (!fp) { puts("ERROR"); return 0; }

fputs("<table border=1><tr><td>\n", fp);
fputs("<table cellpadding=0 cellspacing=0>\n", fp);

for (r = 0; r < ROWS; r++)
{
fputs("<tr>\n", fp);
for (c = 0; c < COLS; c++ )
{
double x = scale(c, 0, COLS - 1, L, R);
double y = scale(r, 0, ROWS - 1, T, B);
size_t i = mand(x, y, MAXITER);
unsigned g = i * 255.0 / MAXITER;
g = 255 - g;
g = g % 16;
g = g * 17;

fprintf(fp, "<td width=\"%d\" height=\"%d\"", SZ, SZ);
fprintf(fp, "bgcolor=\"#%02X%02X%02X\"", g, g, g);
fprintf(fp, "<td></td>\n");
}
fputs("</tr>\n", fp);
}

fputs("</table>\n", fp);
fputs("</td></tr></table>\n", fp);

fclose(fp);
return 0;
}

Which is to say, this has very little to do with C.

I'm sure this would come as a highly confusing shock to the OP
if they had read your statement elsewhere that Facebook can be
implemented in C.

 Try a group related to the platform.

That, I agree with.

 

[Keith Thompson]

There isn't anything platform independent.

Well, you could print one character per pixel, but I'm sure that's not
what the OP is looking for.

Or you could write an image file in some specified format (some
formats are binary, others are plain text) and leave the job of
displaying it up to some other platform-specific tool.

But you're right, there is no platform independent way to display
individual pixels on a screen. (Not all platforms even have screens.)

 

[Wolfnoliir]

Seebs a écrit :

Something suitable to my target platform. The answer would be very different
for the iPhone than it would for a Linux desktop...

Which is to say, this has very little to do with C. Try a group related to
the platform.

-s

Thanks but I would prefer something platform independent.

 

[Ersek, Laszlo]

Seebs a écrit :
Thanks but I would prefer something platform independent.

(I wanted to answer this to your original post, but it's just as
relevant now.)

Compute the image in memory and write it out to a ppm file (P6).

http://en.wikipedia.org/wiki/Netpbm_format

The last time I did this was in 2001 or 2002, when I played with
Overhauser splines. It worked great. You can do anything with a ppm
file.

Cheers,
lacos

 

[Wolfnoliir]

Ersek, Laszlo a écrit :

(I wanted to answer this to your original post, but it's just as
relevant now.)

Compute the image in memory and write it out to a ppm file (P6).

http://en.wikipedia.org/wiki/Netpbm_format

The last time I did this was in 2001 or 2002, when I played with
Overhauser splines. It worked great. You can do anything with a ppm
file.

Cheers,
lacos

Thanks for the answers. I may look this idea of ppm file up but the idea
of having to transfer data into a file before displaying it seems very slow.
I also have the impression that some may have misunderstood me: I am not
talking about putting pixels on the screen directly but in a window
actually. I am sorry that my first message was unclear.

 

[Seebs]

Thanks but I would prefer something platform independent.

Then you are out of luck, because C exists on a broad range of platforms
which don't have "pixels".

Whatever you pick, even if it applies to multiple platforms, you will need
to commit to a set of platforms before you can pick it, and you should
probably pick one of them to start with.

-s

 

[Malcolm McLean]

Hello,
I would like to know what library and method you would recommend for
displaying individual pixels on the screen

I have some knowledge of SDL and OpenGL already.

Write into an off-screen buffer using rgb / palette inddex values.
Then use openGL to transfer the buffer to screen in a signle call.
Unfortunatetly the openGL documentation site is so sophisticated that
it keeps crashing my browser, so I couldn't look up the call for you.
The technical term is "blit".

 

[Ersek, Laszlo]

I also have the impression that some may have misunderstood me: I am not
talking about putting pixels on the screen directly but in a window
actually. I am sorry that my first message was unclear.

I think one of the standard answers is Qt.

http://qt.nokia.com/

Cheers,
lacos

 

[Andrew Poelstra]

I think one of the standard answers is Qt.

http://qt.nokia.com/

Cheers,
lacos

Qt is a quagmire of inconsistencies, undocumented bugs and missing
functionality. And it forces you to use C++, which has all those
problems on its own.

If the OP doesn't want to save to disk, he should see if he can
save a PPM file to memory - which will be nonportable but likely
pretty simple on each platform that he ports to. (Or impossible,
in which case he can save to disk).

Failing that, perhaps a Gdk pixbuf would be portable enough.

 

[Wolfnoliir]

Malcolm McLean a écrit :

Write into an off-screen buffer using rgb / palette inddex values.
Then use openGL to transfer the buffer to screen in a signle call.
Unfortunatetly the openGL documentation site is so sophisticated that
it keeps crashing my browser, so I couldn't look up the call for you.
The technical term is "blit".

This looks like what I am looking for. I'll go look it up. Thank you.

 

[Keith Thompson]

Thanks for the answers. I may look this idea of ppm file up but the idea
of having to transfer data into a file before displaying it seems very slow.
I also have the impression that some may have misunderstood me: I am not
talking about putting pixels on the screen directly but in a window
actually. I am sorry that my first message was unclear.

Please understand that there simply is no platform-independent way to
display pixels, either on a screen, in a window, on a sheet of paper,
or anywhere else. There are plenty of platform-independent ways to
generate data that can then be interpreted *by some platform-specific
program* as pixel data. Or you can generate textual output, with,
say, '*' representing a pixel that's on and ' ' representing a
pixel that's off.

The C language is designed to be imlementable on a wide variety of
systems, some of which don't have graphic displays.

There are add-on various graphics libraries that provide
a platform-independent interface and a platform-specific
implementation. They can't be portable to *all* possible platforms,
but if you just want to support a few systems, that's your best
bet. If you only care about, say, Windows and Unix-like systems,
a solution should be possible. (I'm not familiar enough with such
libraries to offer specific advice.)

 

[Wolfgang Draxinger]

I found glDrawPixels() which seems to work fine.

glDrawPixels is to be considered deprecated, if it's used in conjunction
with rendering other primitives - for just displaying a single image
convering the whole window it's okay, but make sure to use an internal
format, that requires no conversion. Most often this is GL_BGR.

The recommended way to draw pixel images using OpenGL is to first transfer
them into a texture, then render this using a quad. The reasoning behind
this is, that glDrawPixels forces synchronization of the rendering pipeline
thus stalling the rasterizer. Going the way over a pixel buffer object and a
texture allows for asynchronous processing.

Getting texels perfectly screen pixel aligned requires some thinking if
using a "normal" texture. I explained it here http://tinyurl.com/cgndc8

Using a GL_TEXTURE_RECTANGLE instead of GL_TEXTURE_2D it's straightforward.


Wolfgang

 

[bartc]

I found glDrawPixels() which seems to work fine.

glDrawPixels is to be considered deprecated, if it's used in
conjunction... )

If it's any help at this stage, there is also an OpenGL discussion group
comp.graphics.api.opengl

(Although, OpenGL is more for rendering, I wouldn't use it myself for basic
pixel graphics. (I use my own library which makes use of Win32/GDI, but
then I'm only interested in one platform.))

 

[Wolfnoliir]

Wolfnoliir a écrit :

Malcolm McLean a écrit :
This looks like what I am looking for. I'll go look it up. Thank you.

I found glDrawPixels() which seems to work fine.

 

[Squeamizh]

Qt is a quagmire of inconsistencies, undocumented bugs and missing
functionality. And it forces you to use C++, which has all those
problems on its own.

C++ does not have all those problems on its own. I'm not sure why you
would say that.

 

[Andrew Poelstra]

C++ does not have all those problems on its own. I'm not sure why you
would say that.

It does, though. Perhaps I worded that too strongly (it does
look like a flame bait, even to me, though I assure you this
was not my intent.)

See http://www.yosefk.com/c++fqa

for a critique from somebody quite passionate about this issue.

 

[Wolfnoliir]

Wolfgang Draxinger a écrit :

glDrawPixels is to be considered deprecated, if it's used in conjunction
with rendering other primitives - for just displaying a single image
convering the whole window it's okay, but make sure to use an internal
format, that requires no conversion. Most often this is GL_BGR.

The recommended way to draw pixel images using OpenGL is to first transfer
them into a texture, then render this using a quad. The reasoning behind
this is, that glDrawPixels forces synchronization of the rendering pipeline
thus stalling the rasterizer. Going the way over a pixel buffer object and a
texture allows for asynchronous processing.

Getting texels perfectly screen pixel aligned requires some thinking if
using a "normal" texture. I explained it here http://tinyurl.com/cgndc8

Using a GL_TEXTURE_RECTANGLE instead of GL_TEXTURE_2D it's straightforward.


Wolfgang

Thanks. I will look this up when I have time. (for the time being
glDrawPixels() is working well)

I am using GL_RGB format because it seems more natural. Should I try
GL_BGR instead? What difference would it make?
I am also using GL_FLOAT. Would I gain performance by changing it to
GL_UNSIGNED_BYTE?