Board index » delphi » What's wrong with Graphics.pas ??

What's wrong with Graphics.pas ??

As I heard it, "Borland is not in the graphics business".

Joe
code4sale.com - "Your place to buy and sell code"
Delphi "per minute" telephone support is back at code4sale.com

Quote
"Jim Hargis" <jhar...@NOSPAM.uswest.net> wrote in message

news:3a0221a0_2@dnews...
Quote
> Graphics.pas doesn't package the GDI sufficiently.  At least the following
> is needed:
> 1. RotateBitMap
> 2. PLGBLT
> 3. MMX support
> 4. RotateText!
> 5. World Coord to Pixel Coord transforms!
> 6. Text Justification/Alignment
> 7. Rotate Metafile
> 8. BUILT IN OGL support!
> 9. Pan/Zoom Controls
> 10. Alpha Blend (transparency)

> I'm really tired of wading through the GDI to do such simple stuff.  I bet
> each of these have been implemented Hundreds of times in Delphi, and
> thousands of NG questions!  And I'll donate code for 1,4,5,6,9.
> For more suggestions, simply visit the FAQ!

> --

> Jim Hargis
> j...@har-gis.com

> har*GIS LLC
> GIS Engineering Services
> 8093 S Oneida Ct.
> Englewood, CO 80112-3133
> 303/220-0253

 

Re:What's wrong with Graphics.pas ??


snip]

Quote
> > > *  Poor support for 256 colour bitmaps.

The author of the code in question stated back in 1995 that
"users should not be using 256 color graphics cards, and
the problem will eventially go away"

[snip]

Quote
>graphics.pas tries to get a nice 256 color palette using

CreateHalftonePalette
[snip]
Quote
> I know - but they could take a stab at it by defaulting to the 'Safety'

palette,

CreateHalftonePalette is a terrrible and very unreliable solution. I use my
own
code, (especially in my rewritten jpeg unit). Note that  the author of the
code in
question admitted in the book that he wrote that he is lazy. I would suspect
that
this is the reason why a good wash palette is not included in
Graphics.pas...
It would have required someone to type in a 236 element array of colors!

Quote
> > Borland should  have used Joe Hecht's talents better when he
> > worked for them.   Now they should just contract with him to
> > add this missing functionality that would be even better than

StretchDIBits.

A solution for almost every VCL graphic deficiency was offered to Borland
both while I worked there, and afterwards.

Quote
> He's a cool guy.  A bit {*word*216}ly sometimes, but very bright (IMHO) <g>

Thanks. Yes I am very {*word*216}ly! "Hardend" is perhaps a better choice.
This former pillar of the community used to spend $1200 a month
despensing free advice on the old CIS forum back in the days when a
300 baud modem was state of the art. I posted a hundred+++ solutions
a week for years, including posting solutions when I was a Borland
employee (your not supposed to do that except in the install section).
I think between getting kicked around too much, and my total
disgust for knowledgable experts who get caught providing
substandard responses just got me down. I think about all the time
I missed with my family, solving problems for free, then, often enough,
getting kicked over it. Now I am an old grump, {*word*216}ly, and mean.
I hardly ever "give it away for free" anymore. Thanks for the "bright"
comment, but I feel I am overrated in the braincell dept. I will accept
the "cool" comment :)

Joe

Re:What's wrong with Graphics.pas ??


Where is the memory Layout of  Scanline documented (not the pixel format,
which I already have)?

I know the pixel Formats!  I don't know the memory layout of pixels within a
scanline in order to access them.  If I have a Scanline with pf8bit pixels,
can I get the pixel (byte) by direct offset from the scanline?  Or is there
a "header" on the scanline, or a reverse order of pixels from the start of
the scanline or ???

Jim Hargis
j...@har-gis.com

har*GIS LLC
GIS Engineering Services
8093 S Oneida Ct.
Englewood, CO 80112-3133
303/220-0253

Quote
"David Taylor" <david.j.tay...@baesystems.com> wrote in message

news:3a028e1b_2@dnews...
Quote
> ... but for this, Jim, you _must_ know about memory layouts.  Each pixel
> format (8, 16, 24, 32-bits) has a different layout.  If you know the pixel
> format, you can write the code.  I find it sometimes easier to restrict my
> code to a known format than to attempt to deal with _all_ formats.

> David

> "Jim Hargis" <jhar...@NOSPAM.uswest.net> wrote in message
> news:3a021c18_1@dnews...
> > Thanks for the hint! Can I then use pointer arithmetic for addressing
> > pixels? i.e., for PixelFormat=pf8bit, something like:

> > type
> >     pByte=^Byte;
> > var
> >   Pixeli:Byte;
> > begin
> > ...
> > Pixeli  := pByte( Integer(ScanlineN) +  i  )^; ???
> > ...

> > Sorry, I don't know the bitmap memory layouts.
> > --

> > Jim Hargis
> > j...@har-gis.com

Re:What's wrong with Graphics.pas ??


I think all the above items, with the exception of MMX and OGL are strictly
2-D GDI packaging issues, not "graphics business" issues.  Certanly not
anywhere near the complexity of Tchart.  And yes, the VCL is very definitely
in the business of packaging the Windows API.
So, the conclusion must be that Borland is not supporting Graphics VCL,
which is the point of the oroiginal messg in this thread.

--

Jim Hargis
j...@har-gis.com

har*GIS LLC
GIS Engineering Services
8093 S Oneida Ct.
Englewood, CO 80112-3133
303/220-0253

"Joe C. Hecht" <joehe...@code4sale.com> wrote in message
news:3a031552$1_2@dnews...

Quote
> As I heard it, "Borland is not in the graphics business".

> Joe
> code4sale.com - "Your place to buy and sell code"
> Delphi "per minute" telephone support is back at code4sale.com

> "Jim Hargis" <jhar...@NOSPAM.uswest.net> wrote in message
> news:3a0221a0_2@dnews...
> > Graphics.pas doesn't package the GDI sufficiently.  At least the
following
> > is needed:
> > 1. RotateBitMap
> > 2. PLGBLT
> > 3. MMX support
> > 4. RotateText!
> > 5. World Coord to Pixel Coord transforms!
> > 6. Text Justification/Alignment
> > 7. Rotate Metafile
> > 8. BUILT IN OGL support!
> > 9. Pan/Zoom Controls
> > 10. Alpha Blend (transparency)

> > I'm really tired of wading through the GDI to do such simple stuff.  I
bet
> > each of these have been implemented Hundreds of times in Delphi, and
> > thousands of NG questions!  And I'll donate code for 1,4,5,6,9.
> > For more suggestions, simply visit the FAQ!

> > --

> > Jim Hargis
> > j...@har-gis.com

> > har*GIS LLC
> > GIS Engineering Services
> > 8093 S Oneida Ct.
> > Englewood, CO 80112-3133
> > 303/220-0253

Re:What's wrong with Graphics.pas ??


Quote
"Jim Hargis" <jhar...@NOSPAM.uswest.net> wrote in message news:3a03b64b$1_2@dnews...
> Where is the memory Layout of  Scanline documented (not the pixel format,
> which I already have)?

This is all described with examples in the Scanline Tech Note:
http://www.efg2.com/Lab/ImageProcessing/Scanline.htm

I usually use a pByteArray for pf8bit bitmaps (don't forget about palettes) and
a pRGBTripleArray for pf24bit bitmaps:

TYPE
  TRGBTripleArray = ARRAY[WORD] OF TRGBTriple;
  pRGBTripleArray = ^TRGBTripleArray;

--
efg

Earl F. Glynn     E-mail:  e...@efg2.com
Overland Park, KS  USA

efg's Computer Lab:  http://www.efg2.com/Lab

Re:What's wrong with Graphics.pas ??


Quote
"Jim Hargis" <jhar...@NOSPAM.uswest.net> wrote in message news:3a03b74b$1_1@dnews...
> I think all the above items, with the exception of MMX and OGL are strictly
> 2-D GDI packaging issues, not "graphics business" issues.  Certanly not
> anywhere near the complexity of Tchart.  And yes, the VCL is very definitely
> in the business of packaging the Windows API.

> So, the conclusion must be that Borland is not supporting Graphics VCL,
> which is the point of the oroiginal messg in this thread.

Perhaps Kylix will change this.  Since university types are more inclined to use
UNIX and graphics, maybe Borland will make this a higher priority.

--
efg

Earl F. Glynn     E-mail:  e...@efg2.com
Overland Park, KS  USA

efg's Computer Lab:  http://www.efg2.com/Lab

Re:What's wrong with Graphics.pas ??


Jim Hargis schrieb:

Quote

> Where is the memory Layout of  Scanline documented (not the pixel format,
> which I already have)?

Basically, you may consider ScanLine as pointer to an
array[0..Bitmap.Width-1] of pixels.

Quote
> I know the pixel Formats!  I don't know the memory layout of pixels within a
> scanline in order to access them.  If I have a Scanline with pf8bit pixels,
> can I get the pixel (byte) by direct offset from the scanline?  

In that case the bytes are indices into the bitmap's color table.  Let
"bmih" be the BITMAPINFOHEADER of bitmap "Bmp"; then the color of the
pixel at point (X,Y) might be computed as follows (untested):

  with bmih.Colors[PByteArray(Bmp.ScanLine[Y])^[X]] do Color :=
RGB(rgbRed, rgbGreen, rgbBlue);

Quote
> Or is there a "header" on the scanline, or a reverse order
> of pixels from the start of the scanline or ???

Nope.

Greetings, Robert
--
Robert Ro?mair

Re:What's wrong with Graphics.pas ??


Quote
>Where is the memory Layout of  Scanline documented (not the pixel format,
>which I already have)?

>I know the pixel Formats!  I don't know the memory layout of pixels within a
>scanline in order to access them.  If I have a Scanline with pf8bit pixels,
>can I get the pixel (byte) by direct offset from the scanline?  Or is there
>a "header" on the scanline, or a reverse order of pixels from the start of
>the scanline or ???

     The value returned is a pointer to an array of pixels, nothing
fancy.

Re:What's wrong with Graphics.pas ??


Quote
"Loren Pechtel" <lorenpech...@hotmail.com> wrote in message

news:3a04417e.1144767@forums.inprise.com...

Quote
> >Where is the memory Layout of  Scanline documented (not the pixel format,
> >which I already have)?

>      The value returned is a pointer to an array of pixels, nothing
> fancy.

BUT, it not really that simple.

For 24-bit graphics, the bytes are ordered GBR instead of RGB.  For 16-bit vs.
15-bit graphics you need to worry where the extra bit is (for green).
For pf8bit and below you need to worry about palletes.

The Canvas.Pixels is very slow but is easier to use than Scanline.

--
efg

Earl F. Glynn     E-mail:  e...@efg2.com
Overland Park, KS  USA

efg's Computer Lab:  http://www.efg2.com/Lab

Re:What's wrong with Graphics.pas ??


-----------------------------------------------------------------------
This solution is brought to you by Joe Hecht's TExcellent products,
solving Form.Print and bitmap printing problems. Joe Hecht's TExcellent
products can be found at: www.code4sale.com/tryitbuyit/joehecht.htm
-----------------------------------------------------------------------

Quote
>> BUT, it not really that simple.

You are very correct.

Quote
>> For 16-bit vs 15-bit graphics you need to worry where the extra bit is
>> (for green).

Bitfields can be of any format. A 10-4-1 format is still 15 bits of color
depth,
still requires 16 bits of storage, and is a legal windows bitmap format. To
do
this correctly, you must do a quick check for the standard formats you are
referrring to, and then fall out to a general case.

Quote
> For pf8bit and below you need to worry about palletes.

And what about 16, 24, and 32 bit bitmaps that have palettes?

Finally, anyone going to address RLE encoded bitmaps?

Joe

Re:What's wrong with Graphics.pas ??


On Sat, 4 Nov 2000 15:54:58 -0600, "Joe C. Hecht"

Quote
<joehe...@code4sale.com> wrote:
>>> BUT, it not really that simple.

>You are very correct.

>>> For 16-bit vs 15-bit graphics you need to worry where the extra bit is
>>> (for green).

>Bitfields can be of any format. A 10-4-1 format is still 15 bits of color depth,
>still requires 16 bits of storage, and is a legal windows bitmap format. To do
>this correctly, you must do a quick check for the standard formats you are
>referrring to, and then fall out to a general case.

For dib's that only valid for NT, how is this for ddb's?
And how do you get the bitmask for any bitmap?

Just curious :)

- Asbj?rn

Re:What's wrong with Graphics.pas ??


Quote
"Joe C. Hecht" wrote:
> Bitfields can be of any format. A 10-4-1 format is still 15 bits of color
> depth,
> still requires 16 bits of storage, and is a legal windows bitmap format.

Leave it to Joe to come up with perfection...

Seriously, you'll have a hard time trying to come accross any bitfield
arrangement other than the 'standard' ways to code 15bits, 16bits and
32bits RGB (and these are the only bitfield arrangements Win9x can
handle). I do agree that the spec does allow any bitfield format. But
since there are hardly any images like that 'in the wild', one might
also say that the 'de facto spec' differs from the official spec in this
regard. I very much doubt that photoshop will be able to read your
10-4-1 bitmap.

Quote
> And what about 16, 24, and 32 bit bitmaps that have palettes?

Huh? This is the very first time I've ever read about 16, 24 or 32 bit
bitmaps with palettes. Any docs on that, Joe?

Quote
> Finally, anyone going to address RLE encoded bitmaps?

It's not that I really disagree with you. In fact, I find your
profoundness very admireable. But is that virtually non-existent 10-4-1
bitmap really worth hours of hard work? I do feel that, for instance,
RLE does really exist and the 'returns' from supporting it in ones code
do justify the work one puts in, but I doubt that is also the case with
'non-standard' bitfield bitmaps.

Joris

Re:What's wrong with Graphics.pas ??


Lord Crc schrieb:

Quote
> And how do you get the bitmask for any bitmap?

> Just curious :)

Check out the online help topic "BITMAPINFO".

- Robert
--
Robert Ro?mair

Re:What's wrong with Graphics.pas ??


Quote
>> >Where is the memory Layout of  Scanline documented (not the pixel format,
>> >which I already have)?

>>      The value returned is a pointer to an array of pixels, nothing
>> fancy.

>BUT, it not really that simple.

>For 24-bit graphics, the bytes are ordered GBR instead of RGB.  For 16-bit vs.
>15-bit graphics you need to worry where the extra bit is (for green).
>For pf8bit and below you need to worry about palletes.

     He said he already had the pixel format.

Re:What's wrong with Graphics.pas ??


Thanks, I have learned a lot from your site.
I'll submit RotateBitMap with faster indexing when I get it to work.
--

Jim Hargis
j...@har-gis.com

har*GIS LLC
GIS Engineering Services
8093 S Oneida Ct.
Englewood, CO 80112-3133
303/220-0253

"Earl F. Glynn" <EarlGl...@att.net> wrote in message
news:8u1aha$ju2@bornews.borland.com...

Quote
> "Jim Hargis" <jhar...@NOSPAM.uswest.net> wrote in message

news:3a03b64b$1_2@dnews...
Quote
> > Where is the memory Layout of  Scanline documented (not the pixel
format,
> > which I already have)?

> This is all described with examples in the Scanline Tech Note:
> http://www.efg2.com/Lab/ImageProcessing/Scanline.htm

> I usually use a pByteArray for pf8bit bitmaps (don't forget about
palettes) and
> a pRGBTripleArray for pf24bit bitmaps:

> TYPE
>   TRGBTripleArray = ARRAY[WORD] OF TRGBTriple;
>   pRGBTripleArray = ^TRGBTripleArray;

> --
> efg

> Earl F. Glynn     E-mail:  e...@efg2.com
> Overland Park, KS  USA

> efg's Computer Lab:  http://www.efg2.com/Lab

Go to page: [1] [2]

Other Threads