On Mon, 21 Mar 2011, Alexander Klenin wrote:
On Mon, Mar 21, 2011 at 18:40, <[email protected]> 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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
