Help needed with a very silly idea...

[Karlos]

You know, it's an interesting in point.

I know a few people who write the most atrocious code imaginable, simply because they are spoiled by the performance of their hardware. People who should not be let anywhere near a compiler, for that matter. Their only skill is in the application of brute force to solve any problem. Then they use some convenience-oriented, high-level language/design tools with which to write their ill thought out code.

I worry that the arts of problem analysis, algorithm design and implementation efficiency are fast dying.

[Karlos]

bloodline wrote:

Well, I would suggest the shift is from a problem oriented view of program design to a solution one.
Err... We don't need to worry about the implementation of the problem, and instead worry more abotu the outcome of the solution... or something...

Which is a completely bollox approach for this situation. And indeed most of the things I work on.

I guess I like the mental challenges of actually doing something well.

[Karlos]

@ 23JUL/JULES :-)

Thanks for the link. The mechanism there reminds me of a trick used to speed up a mandelbrot generator I tried once. It had a  mask to define already calculated pixels and used this border tracing to determine the region that had reached the iteration limit, bound it off and 'flood fill' the area as being already rendered.

[Karlos]

@Jose

Stay away from 24-bit packed pixel format (3 bytes per pixel). It is surely not of God's pixel representation ;-)

If you need to compare true colour data, have your code load it as 32-bit by expanding with an alpha channel. Even if you don't use the alpha for anything (which increases your datasize by 25%), the benefits of sensible alignment and longword accesses to the data more than make up for it.

I don't know how exactly you are handling your images but it is realtively straightforward to have datatypes load it and then use the DTM_READPIXELARRAY method to extract a 32-bit truecolour (ARGB) representation, even if the source data is not 32-bit.