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

[Peter Nilsson]

Wolfgang Draxinger a écrit :

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?

Why not ask in a group that deals with open gl? Sure, it
saves you time, but it only increases the off topic noise
in clc and decreases your chance of getting quality peer
reviewed responses.

 

[Wolfgang Draxinger]

I am using GL_RGB format because it seems more natural. Should I try
GL_BGR instead? What difference would it make?

It might look more intuitive, but believe it or not, most graphics hardware
store pixels BGR order, oftenly padded to 32 bits with zero-bits prior to
the blue bits.

The history behind this is, that pixels are traditionally stored as unsigned
32 bit MSB integers by graphics hardware, where one could e.g. write
0x00ff0000 for blue, 0x0000ff00 for green and 0x000000ff for red. By storing
as such whole pixels could be manipulated by single instructions, instead of
performing the same instruction 3 times for every pixel. Now if you look at
the memory layout of these in MSB format the rest is ovbious.

I am also using GL_FLOAT. Would I gain performance by changing it to
GL_UNSIGNED_BYTE?

If using glDrawPixels: Yes. The on screen framebuffer most likely uses an
integer format, so floats require conversion first. Now the way glDrawPixels
works, this conversion must be done by the CPU beforehand. If you go the way
over a floating point texture, then conversion is done by the GPU's
rasterizer pipeline.


Wolfgang

F'up 2 c.g.a.opengl

 

[Dr Malcolm McLean]

This is especially evidenced by the fact that he slams C++ for
presenting so many alternate ways of doing things, especially
for having both C features (such as arrays) and C++ features
(such as std::vector).  But I think that's one of the BEST points
of C++, not the worst; it gives the programmer the option of
either doing things "close to the machine" (such as by using
arrays, or malloc/free), or doing things at a higher level of
abstraction (such as with std::vector, or new/delete).

The problem is that basic structure, like arrays / vectors, act as a
protocol by which components of programs communicate with each other.
If some use plain C-style arrays and some use vectors for essentially
the same job, you've got a similar situation to having three or four
different plugs and sockets. Of course you can mess about with
adapters and usually get things to work, but it's messy and
inefficient.

 

[Andrew Poelstra]

Yossi Kreinin is "passionate", all right, but if you read in depth,
You'll see that he doesn't just criticize C++, but says it's
good for nothing, and the wrong choice for EVERY use. He uses
the words "shitty" and "crappy" a lot on his web site in
reference to C++. I get the impression that C++ is just too much
language for him to handle.

This is true. It's unfortunate that he comes off as such a
kook, because he raises some valid points (for example,
the problems with memory management and exceptions, or the
inherent "publicization" of private members.)

 

[Phil Carmody]

"Wolfnoliir" asked:


I chose not to do it that way in my fractal graphing programs.
Instead, I researched the "*.bmp" file format, and write images
to "*.bmp" files.

Why do it that way? Several reasons:
1. You don't need any libraries.
False

2. You don't need any high-level languages.
(The whole thing can be done in C, or even in assembly.)
Irrelevant

3. You don't need any GUIs.
(A simple CLI program can graph fractals this way.)
Irrelevant

4. Why "*.bmp" format? Because it's the simplest and most
widely used of the "lossless" picture file formats.

False. OK, one of your predicates may be true, but for the
conjunction to be true you need both to be true.

5. If you later decide to go from a CLI to a GUI program
for Microsoft Windows, the Win32 API already includes
ability to draw "*.bmp" type bitmaps directly to the screen.

Your argument is on drugs.

The hard part is

So it wasn't the simplest then. Nice of you to shoot your own
prior argument in the foot in the same post.

Phil

 

[Keith Thompson]

False

Oh? What libraries do you need to generate bmp files?

Or were you callling his statement false, with no further explanation,
because he needs the C standard library?

Irrelevant

To whom?

Irrelevant

To whom?

False. OK, one of your predicates may be true, but for the
conjunction to be true you need both to be true.

And if you actually wanted to be helpful, you'd explain further.

(I'd probably use ppm myself.)

[snip]

 

[Phil Carmody]

Oh? What libraries do you need to generate bmp files?

A library which knows about the structure of bmp files. If he doesn't
import a 3rd-party one, he has to write his own. The latter is non-
trivial.

If writing the whole thing yourself was considered 'not needing
any libraries', then 'not needing any libraries' is a completely
weightless predicate.

Or were you callling his statement false, with no further explanation,
because he needs the C standard library?


To whom?

Everyone. He hadn't stated that as a requirement or even desirable
before investigating it, so the fact that he's found something that
satisfies it is irrelevant.

To whom?
Ditto.


And if you actually wanted to be helpful, you'd explain further.

"Do more research. Start at the wikipedia page for image file formats."

(I'd probably use ppm myself.)

Any of the PNM family, depending on the requirements. For simplicity,
they're hard to beat.

Phil

 

[Phil Carmody]

[...]
I chose not to do it that way in my fractal graphing programs.
Instead, I researched the "*.bmp" file format, and write images
to "*.bmp" files.

Why do it that way? Several reasons:
1. You don't need any libraries.
False
Oh? What libraries do you need to generate bmp files?

A library which knows about the structure of bmp files.

No, you don't.

If he doesn't import a 3rd-party one, he has to write his own. The
latter is non-
trivial.

Actually, I disagree. It's trivial, especially if you are only
interested in, say, 24-bit ascending-row-order bitmaps.

Quite possibly. I have a feeling that when the w2k source was leaked
that it was in the 24-bit bitmap handling that I found a buffer
over-run within 20 minutes of opening the zip, though. (OK, on the
reading side, not the writing side.)

And, if you're being picky enough to call a handful of helper routines
a "library", I can be picky enough to add that it's only a library if
you build a library out of those helper routines. There's nothing to
stop you putting them in your application source. (Not that you
*would* do that, but it's *possible*.)

So no, you don't need a library for bitmap format support.

But you don't need a library for anything, as anything that
can be written in a library you can write yourself, given
sufficient time and effort.

The point is that writing the whole thing yourself is trivial and
quick. It's not like, say, JPEG, where you actually need to either use
a third-party library or do some serious research and a fair bit of
programming.

They are still shades of grey on a continuum.

Would you argue with "the most widely used, and one of the simplest,
"lossless" picture file formats"?

Yes. I would argue with that in the sense that I would use it as
my argument with which to argue against others.

I guess I've dealt with half a dozen lossless formats that are
at least as simple as BMP, but none could compare on how widely
they're used.

Phil

 

[Dr Malcolm McLean]

I guess I've dealt with half a dozen lossless formats that are
at least as simple as BMP, but none could compare on how widely
they're used.

Three problems with BMP. Firstly the line-padding rules. Since most
images are units of 8 pixels wide, these often grab ypu unexpectedly.
The second one is that all the documentation assumes you will be
running the code on a Windows machine. In fact it is not possible to
portably define the headers in terms of structures. However it's easy
eanought o write a fucntionto read a little-endian integer from the
file.

The third one is the BGR, upside down raster format. It's just a
little bit of tinkering, but it's a nuisance, and it tempts you to
give your loader a cluntzy interface.

 

[bartc]

Three problems with BMP. Firstly the line-padding rules. Since most
images are units of 8 pixels wide, these often grab ypu unexpectedly.
The second one is that all the documentation assumes you will be
running the code on a Windows machine. In fact it is not possible to
portably define the headers in terms of structures. However it's easy
eanought o write a fucntionto read a little-endian integer from the
file.

Yes, the header is some 54 bytes I think, while scanlines are a multiple of
4 bytes. That means the entire image data, and any palette, are at an odd
2-byte alignment in the file, and in memory if you just load the whole thing
as one block.

(BMP was also used at one time for combining multiple icons in a single BMP
image. Each scanline row is padded to a 4n bytes, so the natural way to do
this is to combine these vertically.

So that if the icon is, say, 20x20 1-bit pixels, the 3rd icon starts at row
41 in the composite file. But it was decided to pack these horizontally
instead. Now the start of any row in the 3rd icon, starts at some bit offset
in the middle of the 2nd dword! Who designs this stuff?)

The third one is the BGR, upside down raster format. It's just a
little bit of tinkering, but it's a nuisance, and it tempts you to
give your loader a cluntzy interface.

I think the palette uses RGB, and the image data might use BGR. Or is it the
other way. (Palettes and 24-bit image data do not co-exist, doesn't help
though).

But on the whole, compared with some file formats, BMP is fairly
straightforward.

 

[Sjouke Burry]

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.

I once wrote a wildcard bmp viewer for Dos, showing how the
structure is implemented.
It shows 2/4/4rle/8/8rle/and 24 bit rgb decoding and the diffs
between OS2 and M$ .
If you want the sourcecode, ask here or try to de-louse
my email adress.

 

[Dr Malcolm McLean]

Actually, it is. The non-portability comes not from structure defs, but
from unwarranted assumptions about alignment and endianness...

They used to document the format in terms of C-language structures. I
can't actually find any of the official Microsoft docs on the web,
though there is no shortage of unofficial BMP format specs.

 

[Richard Bos]

A library which knows about the structure of bmp files. If he doesn't
import a 3rd-party one, he has to write his own. The latter is non-
trivial.

Nonsense. _Reading_ everyone else's widely varying BMP files, that's
non-trivial. Choosing one format for yourself to use and writing BMP
files in that format only, that's a very simple job.

Richard

 

[Ian Collins]

Well, yah. C++ is messy and inefficient. C is less messy,
but also less efficient in some ways (such as effort required
to set up data structures such as multimap of struct objects),
and also more efficient in other ways (the executables are
noticably smaller and faster than the same program written
in C++).

While not wanting to get into a religious war, that is complete nonsense.

> But I like and use both languages, along with others.

Good, use the best tool for the job.

 

[jacob navia]

Robbie Hatley a écrit :

group, in response to my message about the ways in which I chose
to graph fractals with C programs writing images to bmp files:


No, Phil, there was nothing "false" or "irrelevant" in the post
you were pretending to be replying to.


No. But the easiest thing for *ME* (and others here) to do,
is, indeed, to killfile you. Life is short, and there's no time
for fussing and fighting with enfant provocateurs.

::: killfiles "Phil Carmody" ( (e-mail address removed) ) :::

Done.

I suggest everyone here do likewise.

Look, I have never "killfiled" anyone.

I just don't read what carmody writes, and that is much easier. Why bother?

 

[Default User]

On Fri, 19 Mar 2010 23:13:51 +0100


Exactly! you don;t have to read.

If you never plan to read the posts of a certain person, why not
killfile them?



Brian

 

[Seebs]

I don;t see reason in filterng messages, except that
messages are pure spam and there is no purpose replaying

How about "they annoy me and waste my time"? That's why I usually
killfile people.

-s

 

[Dr Malcolm McLean]

Good, use the best tool for the job.

No. Introduce another language only if the case for it is
overwhelming.

 

[Ian Collins]

No. Introduce another language only if the case for it is
overwhelming.

What do you mean by "Introduce another language"?

If I have to write a web application, I use PHP and JavaScript. Should
I use C?

If I have to automate a system administration task, I use bash or ksh.
Should I use C?

There's always an appropriate tool for a job.

 

[Seebs]

In rare occasions even some annoying people post interesting things
(to a certain degree), that's why I never killfile people...

If I read enough conspiracy-theorist web sites, I'll eventually encounter
a fact. This doesn't mean it's a good use of my time.

If I had infinite time, I would not use a killfile.

-s