[Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin klenin at gmail.com
Mon Mar 21 10:40:29 CET 2011


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.

> 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. 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.
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.

> 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.
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.
2) TPen/TBrush/TFont -- I can not simply replace these with
the FP versions, since it will be a serious loss of functionality.
Fonts are most problematic.
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.

-- 
Alexander S. Klenin




More information about the Lazarus mailing list