[Lazarus] Get JPEG from TAChart in CGI app

[michael.vancanneyt at wisa.be]

On Mon, 21 Mar 2011, Alexander Klenin wrote:

> On Mon, Mar 21, 2011 at 18:40,  <michael.vancanneyt at wisa.be> wrote:
>>> I wonder how much overhead it is for a cgi program to start gtk on xvfb
>>> compared to a fpcanvas program.
>>
>> A lot. A connection to the X server must be established, and the whole
>> of GTK must be set up. This is an expensive operation.
>
> True, although something like FastCGI may alleviate startup costs.

>
>> I can't believe people even consider this approach. It's like PHP devels
>> would suddenly say that "well, from now on you must run your web apps with
>> an X server". They would be the laughing stock of the whole PHP programmer's
>> community.
>>
>> Yet, in lazarus, no-one seems to mind this kind of statements. It's even
>> encouraged.
>
> 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 :(

>
>> 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. 
Color depth is only needed when displaying on screen, because the screen 
has a 'color depth'; namely the number of colors it can display in a pixel.

Green is green. It means RB=0, G=max value; No matter what the color depth is...

> And while other paremeters (especially fonts) are not
> required for bitmap, they are definitely required to draw a chart on it.
> There are many ways to specify drawing parameters and primitives,
> and using widgetset is quite valid way.

Here I differ in opinion. 
If what you are saying is true, things like PostScript could never exist.
And PHP makes very nice charts without screen.

> I even suspect that in many cases widgetset drawing is faster than
> pure FPCanvas.
> 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...

>> When making a picture with a digital camera, the camera also has no
>> knowledge of the screen you'll be displaying the picture on. Nevertheless,
>> it makes pictures.
>
> When used at web-server, TChart also has no knowledge of the screen
> the chart will de displayed on.

Rightly so, it does not need it.

> And to not tell me that digital cameras are not aware of the
> parameters of their own
> screens ;-)
>
> 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.

> 2) TPen/TBrush/TFont -- I can not simply replace these with
> the FP versions, since it will be a serious loss of functionality.

Why ? As far as I know, all operations in LCL are present in fpImage.
If some are missing, we can implement them.

> Fonts are most problematic.

Again, why ? the FreeType engine can be used to render any text in any
available font on a bitmap.

(Although I admit that the interface currently is rather clumsy, and could
use some improvements - some kind of font factory is needed.)

> Solutions I imagine now involve rather messy set of interfaces and/or
> generic classes,
> which are hard to get right and will not be easy to maintaing.
> 3) Events -- this is trivial compared to above, but still -- existing
> TChart events often pass
> TCanvas as a parameter. This can be solved easily by breaking
> backwards compatibility,
> but I am reluctant to do this.

I understand it is not easy.

You suffer the same problem as the reporting engines. They are designed on
top of a GUI, when in fact there is no need for this. They need an abstract
canvas, representing a sheet of paper on which to Draw. PostScript can do
it, and so can Pascal.

Again, I don't claim it is easy, but I regret that everyone starting a set of
components time and again takes the same road...

Well. 
Very likely I'll need charting in a web project of mine. At that time,
I'll probably have to re-implement TAchart on top of TFPImage :(

One thing should be clear: none of what I say implies that I think TAChart
is a bad component. It's probably well written for a GUI, but unfortunately 
not suitable for a Web environment in my opinion.

Michael.