BGRABitmap tutorial

[Ask]

Ok. I've copied it (i've changed procedure to function).

I do not see it. In which unit did you put it?

Looking at the line drawing code, I do not see any references to the PenStyle --
maybe you forgot to implement it?

Found it -- you implemented PenStyle for some, but not all line drawing routines.
Changed my code to call supported ones -- still, maybe you want to document this
limitation, as I think it might confuse novice users of BGRABitmap.

Also, my patch in the previous post was against non-tip revision of BGRABitmap.
See attached rebased patch.

[circular]

You might want to read some fpc-devel threads on the topic --
then you will see what real negative posts look like

It's sad if they are negative with each others. I did not mean that I cannot accept a negative report. I suppose that you understand what I mean.

That's easy -- see attached patch.
Obviously, it may be improved -- for example, you might want to add (and then use)
refcounting for the interface, add the rest if methods to it,
put it in a separate unit intead of TBGRABitmapTypes etc.
I just did a minimal patch for easier review.

I will look at that.

...dashed lines did not work...

What happens?

Nothing -- lines always are drawn solid.
Looking at the line drawing code, I do not see any references to the PenStyle --
maybe you forgot to implement it?

There are many procedures. Some of these do not take a width w as parameter, and do not implement pen styles.

BTW, you might want to use include files to reduce the code duplication between
line drawing procedures without loss of speed.

Why not. What do you suggest exactly ?

This is indeed a serious problem -- I think that the decision of FPC developers
not to implement TColor was a mistake. I did not yet give up a hope of
convincing them to fix it.

You mean that TFPCustomCanvas should include TColor ?

Meanwhile, I think some support of TColor is a must -- there is just
too much code using it.
I suggest the following plan:
1) Internally, use whatever works fastest -- I guess it is TBGRAPixel
2) Provide a functions for conversions with TFPColor/TColor/TColor+Opacity in both directions
(this is already almost done)

That's right, it's already the case.

3) Provide pen/brush interface -- I believe it is far too entrenched to break now,
and besides, it is not really so bad.
5) Provide TCanvas emulation and discuss with Lazarus developers the standard interface
for opacity in TFPCanvas/TCanvas.

Where can we contact them on this issue ?

If we make TBGRACanvas to be like TCanvas, it seems to me that the simplest way is to add an Opacity property as a byte. If we use TBGRAPixel internally, then we could have three properties :
- Color: TColor
- Opacity: Byte
- ColorBGRA: TBGRAPixel

Then to set FPColor, it would be like :
- ColorBGRA := BGRA(SomeFPColor);
or
- ColorBGRA := FPColorToBGRA(SomeFPColor);

Or we could add a fourth property to pen and brush
- ColorFP: TFPColor

You did not say anything about class compatibilities, so I suppose you agree that we cannot derive such canvas from TCanvas. By the way, I realised that anyway, TBGRACanvas cannot be fully compatible, because coordinates are floating numbers, unless we add each function twice (one version of integers and one version for single).

4) (in the future, this is not quite simple)
Put TColor-related functions in a separate unit, and
remove dependencies on Graphics unit in all other code. This will allow
to use BGRABitmap without LCL widgetset -- for example, in web applications.

Why not.

[circular]

Ok, i've applied your patch. It works.

Now if I apply it to BGRAResample for example, I need to change many references to TBGRADefaultBitmap. In fact, TBGRADefaultBitmap was also a sort of interface. It would be also possible to create an abstract class, but the problem would be the same, changing all references to TBGRADefaultBitmap to some TBGRAGenericBitmap.

I suppose the interface is a better solution, because it avoids creating virtual functions and includes automatic reference counting. Thank you for this idea.

Is it possible to link actual reference counting functions to interface reference counting functions ?

[Ask]

There are many procedures. Some of these do not take a width w as parameter, and do not implement pen styles.

Hm, it seems what it is actually the reverse -- those procedures that take width as parameter,
do implement PenStyle, others do not.

You mean that TFPCustomCanvas should include TColor ?

Yes. Even if it will not support "system" colors.

Where can we contact them on this issue ?

On the mailing list -- see this thread http://www.mail-archive.com/lazarus@lists.lazarus.freepascal.org/msg18414.html for a recent discussion
of TCanvas/TFPCanvas in relation to TAChart and widgetset-less drawing.

we could have three properties :
- Color: TColor
- Opacity: Byte
- ColorBGRA: TBGRAPixel

good.

Or we could add a fourth property to pen and brush
- ColorFP: TFPColor

No need -- TFPCustomPen/TFPCustomBrush (and so, all descendants) already have
FPColor property, which is automatically synchronized with Color in TPen/TBrush.
I think TBGRAPen/TBGRABrush should automatically synchronize all
FPColor/Color+Opacity/BGRAPixel properties.

I suppose you agree that we cannot derive such canvas from TCanvas

Of course -- that would defeat idea of widgetset independence.
Currently, this means that you will have to write much duplicate/trivial "glue" code.
However, I hope that either TFPCustomCanvas will be extended or
Lazarus will create TCustomCanvas to reduce the interface gap.
I have already some promises from one FPC developer in the thread cited above.

TBGRACanvas cannot be fully compatible, because coordinates are floating numbers, unless we add each function twice

You do not need to add every function twice -- only those that are present in
TCanvas, and they are quite few compared to what you have in BGRABitmap.
Also, I have noticed that you already overloaded some functions
to receive integers -- so I assume you have a need for this besides TCanvas compatibility.

[Ask]

Is it possible to link actual reference counting functions to interface reference counting functions ?

You mean you want to implement _AddRef/_Release?
Of course it is possible -- the easiest way is to copy them from TInterfacedObject.

[circular]

Now BGRABitmap package avoids semi-circular references (updated on subversion and as a zip file).

[circular]

There are many procedures. Some of these do not take a width w as parameter, and do not implement pen styles.

Hm, it seems what it is actually the reverse -- those procedures that take width as parameter,
do implement PenStyle, others do not.

Nope, it was correct.

You mean that TFPCustomCanvas should include TColor ?

Yes. Even if it will not support "system" colors.

The problem is maybe that TColor is ambiguous, it can mean plain RGB or a reference to a system color.

Where can we contact them on this issue ?

On the mailing list -- see this thread http://www.mail-archive.com/lazarus@lists.lazarus.freepascal.org/msg18414.html for a recent discussion
of TCanvas/TFPCanvas in relation to TAChart and widgetset-less drawing.

I'm not use to this.

Also, I have noticed that you already overloaded some functions
to receive integers -- so I assume you have a need for this besides TCanvas compatibility.

Nope, it's just that some line drawing functions use Bresenham algorithm. They are available for convenience only.

[VTwin]

This is great circular. I just ran LazPaint 2.6 on OS X 10.6, seems to work well. I tried to open 2.8, but the zip file gave me an error.

Where can I find bgrabitmappack.lpk?

Many thanks for working on this and making it available.

Cheers,
Frederick

[circular]

I suppose the upload went wrong. Here I uploaded it again.

Try downloading lazpaint2.8.zip again.
http://sourceforge.net/projects/lazpaint/files/lazpaint/lazpaint2.8.zip/download

You can also use subversion to get version with current modifications. If you have Windows, you need TortoiseSVN for this and then checkout https://lazpaint.svn.sourceforge.net/svnroot/lazpaint.

[gyts]

Will there will be more tutorials like this one? I suck on english :/

[circular]

You mean tutorials on BGRABitmap or on other Lazarus components or on FreePascal in general ?

[gyts]

You mean tutorials on BGRABitmap or on other Lazarus components or on FreePascal in general ?

BGRABitmap.

Edit: For me, any tutorial is useful.

[circular]

I could do other tutorials about BGRABitmap. More precisely, what subject interests you ?

[CaptBill]

I could do other tutorials about BGRABitmap. More precisely, what subject interests you ?

Hello Circular,
What would be nice is a simple demo like the tutorial (first example w/boxes) which outlines the calling of bezier curves. I tried to implement it like in the demo from the download (ttestdemo I think?) but I keep getting some type of scoping issue w/tpanel when I cut and past to my project. It say's "'got DynArray and requested openarray".

A simple form with a panel set up with a bezier curve predrawn, bare minimum to show the calling and initialization etc. That would be perfect. Maybe a button for each type of curve. Something we can use as a template for us newbies.

Thanks

[VTwin]

I suppose the upload went wrong. Here I uploaded it again.

Try downloading lazpaint2.8.zip again.
http://sourceforge.net/projects/lazpaint/files/lazpaint/lazpaint2.8.zip/download

You can also use subversion to get version with current modifications. If you have Windows, you need TortoiseSVN for this and then checkout https://lazpaint.svn.sourceforge.net/svnroot/lazpaint.

That seems to have fixed it. I'm primarily on Mac, have not yet delved into using subversion.

Thanks very much circular, I'm trying it out now.