[Lazarus] Get JPEG from TAChart in CGI app

[Mattias Gaertner]

On Mon, 21 Mar 2011 11:25:12 +0100 (CET)
michael.vancanneyt at wisa.be wrote:

>[...]
> > Using widgetset is perhaps not the ideal solution, but the practical one,
> > given the contraints of existing tools.
> > Surely they may be improved, but that is not fast not easy to do.
> 
> Correct. Unfortunately, no-one seems to be willing to take on the task :(

Huh?
AFAIK you can do quite a lot with fpcanvas. You
can use fonts. But using fonts is not very comfortable because you have
to search and load it yourself.


> >> None of "theme,  screen color depths and sub pixel rendering parameters" are
> >> necessary to create a bitmap. A bitmap is a matrix of pixels with a certain
> >> color. No more, no less. Some of these parameters are needed when the bitmap
> >> is being displayed, but definitely not when it is created.
> >
> > I am not sure how you could create a bitmap without (at least implicitly)
> > specifying color depth.
> 
> There is no need for 'color depth'. A color is 4 words; that's it. 

48bit for each pixel costs a lot of mem and speed.
But it is easy with fpimage to define a RGB 8bit image or RGBA or
grayscale.


>[...]
> > I even suspect that in many cases widgetset drawing is faster than
> > pure FPCanvas.

Why?
AFAIK in cgi you can not use the hardware acceleration.


> > Now, the fact that a widgetset tries to access *screen* to create a bitmap
> > is a problem, I would even call it a bug, although I do not know if it
> > is in GTK or LCL.
> 
> I suppose the LCL, because most likely it asks some system metrics (DPI etc). 
> The widgetset can only get them from the display...

Since you are the second to blame the LCL, let's try the most simple
gtk program:

program test1;
uses gtk2;
begin
  gtk_init(nil, nil);
end.   

$ ./test1 

(test1:3683): Gtk-WARNING **: cannot open display: 


The gtk is made for the screen, not for cgi. Maybe you can use
gtk's drawing backend cairo without a display.


>[...]
> > Still, as I have already said, I argee that FPCanvas-based TChart
> > would be a good idea
> > (actually, even FPCCanvas might not be needed in case of SVG back-end),
> > and I am already slowly working on it for the last few months.
> > Some of the problems I face:
> > 1) TColor vs TFPColor -- I would very much prefer if TColor concept
> > together with all Color properties would be moved to the FPImage.
> > It is the primary source of incompatibility and confusion.
> > I think I know how to handle it, but it will not be pretty.
> 
> Well, I suppose a 'simplified' color handling could be introduced in fpImage.

TColor does not support alpha.
And TColor has some VCL/LCL specific special colors.
I don't see the point integrating that into fpimage.

 
>[...]

Mattias