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.