[Lazarus] Get JPEG from TAChart in CGI app

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Leonardo M. Ramé
On 2011-03-20 18:16:00 -0300, Leonardo M. Ramé wrote:

> On 2011-03-20 20:16:19 +0000, Henry Vermaak wrote:
> > On 20 March 2011 19:42, Leonardo M. Ramé <[hidden email]> wrote:
> > > On 2011-03-21 05:39:01 +1000, Alexander Klenin wrote:
> > >> On Mon, Mar 21, 2011 at 05:30, Leonardo M. Ramé <[hidden email]> wrote:
> > >> >> You have to link you CGI app with some graphic widgetset,
> > >> >> which will unfortunately bloat an executable, but should otherwise work.
> > >> >>
> > >> >
> > >> > Well, I tested that, but I get "Internal Server Error" from my Apache.
> > >>
> > >> What does the log show?
> > >>
> > >
> > > [Sun Mar 20 16:30:09 2011] [error] [client ::1] (cgicharts:16246):
> > > Gtk-WARNING **: cannot open display:
> >
> > Try using xvfb.  This uses a virtual framebuffer that doesn't need a
> > display.  I've had to use it with a webserver before.
> >
> > Henry
> >
>
> Thanks Henry, it seems to almost work, at least I don't get the Cannot
> Open Display error, but...
>
> When I do this:
>
>     lChart.Width := 100;
>     lChart.Height := 100;
>     with lChart.SaveToImage(TJPEGImage) do
>     begin
>       SaveToStream(AResponse.ContentStream);
>       AResponse.ContentType := 'image/jpeg';
>       AResponse.ContentLength := AResponse.ContentStream.Size;
>       AResponse.SendContent;
>     end;
>
> I get a black square of 100 x 100 pixels.
>
> If I try this:
>
>     lChart.SaveToBitmapFile('test.bmp');
>
> I get the error "Image palette is too big or absent" from my CGI.
>

Sorry Henry, the correct command to run Xvfb is this:

Xvfb :12 -screen 0 1024x768x16 &

Now it works!

--
Leonardo M. Ramé
http://leonardorame.blogspot.com

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Mattias Gaertner
In reply to this post by Alexander Klenin
On Mon, 21 Mar 2011 04:58:18 +1000
Alexander Klenin <[hidden email]> wrote:

> On Mon, Mar 21, 2011 at 04:46, Michael Van Canneyt
> <[hidden email]> wrote:
> >> Why do you think so?
> >> TAChart should be prefectly capable of rendering on bitmap-based canvas.
> >
> > Because both TCanvas and TBitmap suppose a GUI. TFPCustomCanvas does not.
> >
> > Yes, I know about the 'nogui' widgetset, and no, I don't think that's a
> > proper solution.
>
> Hm. For me GUI means "graphical user interface" -- that is, windows (aka forms),
> interacting with mouse, etc.
> I have just committed a demo which does not have any of this,
> and yet successfully draws TChart to a file -- see previous mail.
> Maybe for you GUI means a different thing?

Yes. The GUI of the screen.
By accessing the LCL canvas you access the widgetset (gtk2) which
accesses the current screen. For example the gtk2 asks for
theme, fonts, screen color depths and sub pixel rendering parameters.
A cgi program has no screen.
The LCL canvas is an implementation of the abstract TFPCustomCanvas,
and uses a widgetset to render. The nogui widgetset does not implement
rendering, so you can not draw with it.
There are other implementations of TFPCustomCanvas without the need
of a screen. The fcl provides one. Probably TAggFPCanvas can work
without screen too. The last time I checked the main problem is the
font support. It is far less comfortable as the LCL.
It is a good idea to add a render function to TAChart for
TFPCustomCanvas.


Mattias


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin
On Mon, Mar 21, 2011 at 08:41, Mattias Gaertner
<[hidden email]> wrote:

> On Mon, 21 Mar 2011 04:58:18 +1000
> Alexander Klenin <[hidden email]> wrote:
>> Hm. For me GUI means "graphical user interface" -- that is, windows (aka forms),
>> interacting with mouse, etc.
>> I have just committed a demo which does not have any of this,
>> and yet successfully draws TChart to a file -- see previous mail.
>> Maybe for you GUI means a different thing?
>
> Yes. The GUI of the screen.
> By accessing the LCL canvas you access the widgetset (gtk2) which
> accesses the current screen. For example the gtk2 asks for
> theme, fonts, screen color depths and sub pixel rendering parameters.
> A cgi program has no screen.

It is ok to ask for all these things since thay are necessary to
render the chart.
However, the fact they are unconditionally taken from the screen is IMO
a deficiency of either GTK or LCL-GTK.
As you can see in this thread, as soon as this deficiency is worked around,
(in this case, by using Xvfb utility), the problem is solved.

> There are other implementations of TFPCustomCanvas without the need
> of a screen. The fcl provides one. Probably TAggFPCanvas can work
> without screen too. The last time I checked the main problem is the
> font support. It is far less comfortable as the LCL.

Also, AggPas supports neither Pen.Style not Brush.Style.

> It is a good idea to add a render function to TAChart for
> TFPCustomCanvas.

Generally, yes.
But as I stated in the previous mail, simply adding a function may not help.
Still, I am working on this ;)

--
Alexander S. Klenin

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Mattias Gaertner
On Mon, 21 Mar 2011 11:53:52 +1000
Alexander Klenin <[hidden email]> wrote:

> On Mon, Mar 21, 2011 at 08:41, Mattias Gaertner
> <[hidden email]> wrote:
> > On Mon, 21 Mar 2011 04:58:18 +1000
> > Alexander Klenin <[hidden email]> wrote:
> >> Hm. For me GUI means "graphical user interface" -- that is, windows (aka forms),
> >> interacting with mouse, etc.
> >> I have just committed a demo which does not have any of this,
> >> and yet successfully draws TChart to a file -- see previous mail.
> >> Maybe for you GUI means a different thing?
> >
> > Yes. The GUI of the screen.
> > By accessing the LCL canvas you access the widgetset (gtk2) which
> > accesses the current screen. For example the gtk2 asks for
> > theme, fonts, screen color depths and sub pixel rendering parameters.
> > A cgi program has no screen.
>
> It is ok to ask for all these things since thay are necessary to
> render the chart.
> However, the fact they are unconditionally taken from the screen is IMO
> a deficiency of either GTK or LCL-GTK.

The display error comes from the gtk.


> As you can see in this thread, as soon as this deficiency is worked around,
> (in this case, by using Xvfb utility), the problem is solved.

I wonder how much overhead it is for a cgi program to start gtk on xvfb
compared to a fpcanvas program.


Mattias

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

michael.vancanneyt


On Mon, 21 Mar 2011, Mattias Gaertner wrote:

> On Mon, 21 Mar 2011 11:53:52 +1000
> Alexander Klenin <[hidden email]> wrote:
>
>> On Mon, Mar 21, 2011 at 08:41, Mattias Gaertner
>> <[hidden email]> wrote:
>>> On Mon, 21 Mar 2011 04:58:18 +1000
>>> Alexander Klenin <[hidden email]> wrote:
>>>> Hm. For me GUI means "graphical user interface" -- that is, windows (aka forms),
>>>> interacting with mouse, etc.
>>>> I have just committed a demo which does not have any of this,
>>>> and yet successfully draws TChart to a file -- see previous mail.
>>>> Maybe for you GUI means a different thing?
>>>
>>> Yes. The GUI of the screen.
>>> By accessing the LCL canvas you access the widgetset (gtk2) which
>>> accesses the current screen. For example the gtk2 asks for
>>> theme, fonts, screen color depths and sub pixel rendering parameters.
>>> A cgi program has no screen.
>>
>> It is ok to ask for all these things since thay are necessary to
>> render the chart.
>> However, the fact they are unconditionally taken from the screen is IMO
>> a deficiency of either GTK or LCL-GTK.
>
> The display error comes from the gtk.
>
>
>> As you can see in this thread, as soon as this deficiency is worked around,
>> (in this case, by using Xvfb utility), the problem is solved.
>
> 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.

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.

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.

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.

Michael.

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin
On Mon, Mar 21, 2011 at 18:40,  <[hidden email]> 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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

michael.vancanneyt


On Mon, 21 Mar 2011, Alexander Klenin wrote:

> On Mon, Mar 21, 2011 at 18:40,  <[hidden email]> 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
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Mattias Gaertner
On Mon, 21 Mar 2011 11:25:12 +0100 (CET)
[hidden email] 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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin
In reply to this post by michael.vancanneyt
2011/3/21  <[hidden email]>:

>>  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 :(

But I am willing, and doing it right now ;)

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

Please do not conflate "screen" with "widgetset".

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

That is a deficiency that could be fixed.

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

For starters, the absence of following is most problematic:

Canvas.FillRect
Canvas.RadialPie
Font.Orientation

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

I did not start TAChart, but I do try to improve it's design.

> 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 :(
>

If you implement the missing parts of FPCanvas,
there is a good chance you will not have to re-implement TAChart ;)


--
Alexander S. Klenin

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin
In reply to this post by Mattias Gaertner
On Mon, Mar 21, 2011 at 21:04, Mattias Gaertner
<[hidden email]> wrote:
> On Mon, 21 Mar 2011 11:25:12 +0100 (CET)
> [hidden email] wrote:
>
> Why?
> AFAIK in cgi you can not use the hardware acceleration.

Because color manupulation in 16-bit depth may be slower than in 8-bit,
and because even withouh acceleration, OS drawing functions may be much
better optimized then FPPCanvas ones.

> Since you are the second to blame the LCL, let's try the most simple gtk program:
...
>  gtk_init(nil, nil);

Well, of course. The question is -- should LCL call gtk_init even if
no gtk functions are called?
Maybe initializing gtk_pixbuf would be enough for TBitmap?

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

It would avoid ugly workarounds like the one I am writing for TAChart now.
Anyway, this is not a huge problem -- just some code duplication.

--
Alexander S. Klenin

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

michael.vancanneyt
In reply to this post by Mattias Gaertner


On Mon, 21 Mar 2011, Mattias Gaertner wrote:

> On Mon, 21 Mar 2011 11:25:12 +0100 (CET)
> [hidden email] 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.
You don't need it, either.

When generating a bitmap, I don't see how hardware accelleration
of the graphics card comes into play ?
When generating a bitmap 'on screen', the double buffering mechanism
means that
a) you somehow create it in memory
b) it is then moved 'accelerated' to screen.
and in 95% of cases, even without double buffering, this is the mechanism
used.

Since CGI only needs step a), the 'acceleration' is not needed.

>>> 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:
Obviously, but AFAIK it is the LCL that calls gtk_init ?
Simply linking to GTK doesn't open a display, I presume.

Michael.
--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

michael.vancanneyt
In reply to this post by Alexander Klenin


On Mon, 21 Mar 2011, Alexander Klenin wrote:

> 2011/3/21  <[hidden email]>:
>
>>>  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 :(
>
> But I am willing, and doing it right now ;)

Glad to hear it :)

>
>>> 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.
>
> Please do not conflate "screen" with "widgetset".

In my opinion "No screen => no widgetset." ?

>
>>> 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...
>
> That is a deficiency that could be fixed.
>
>> Why ? As far as I know, all operations in LCL are present in fpImage.
>> If some are missing, we can implement them.
>
> For starters, the absence of following is most problematic:
>
> Canvas.FillRect
> Canvas.RadialPie
> Font.Orientation

FillRect and RadialPie can be solved easily. The Font.Orientation can be
added as a property, I would have to look at FreeType to see how it can be
implemented. Consider it on the todo list. I can add the missing
properties/methods quickly, their implementations may take slightly longer
:-)


>
>> 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...
>
> I did not start TAChart, but I do try to improve it's design.

Great =-)

>
>> 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 :(
>>
>
> If you implement the missing parts of FPCanvas,
> there is a good chance you will not have to re-implement TAChart ;)

I will try to do so ASAP.

Michael.

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Mattias Gaertner
In reply to this post by Alexander Klenin
On Mon, 21 Mar 2011 21:49:38 +1000
Alexander Klenin <[hidden email]> wrote:

> On Mon, Mar 21, 2011 at 21:04, Mattias Gaertner
> <[hidden email]> wrote:
> > On Mon, 21 Mar 2011 11:25:12 +0100 (CET)
> > [hidden email] wrote:
> >
> > Why?
> > AFAIK in cgi you can not use the hardware acceleration.
>
> Because color manupulation in 16-bit depth may be slower than in 8-bit,
> and because even withouh acceleration, OS drawing functions may be much
> better optimized then FPPCanvas ones.

Maybe, maybe not.
In case of gtk I doubt that *many* functions are much faster.
In my measurements the difference between 16 vs 8bit was not
big. It made a big difference if your bitmap is 16bit. I recommend to
not use the default fp memory image. Writing a 8bit is easy. It would
be nice if fpimage would provide some other memory image
implementations. For example 8bit RGB, RGBA and
Grayscale.

 
> > Since you are the second to blame the LCL, let's try the most simple gtk program:
> ...
> >  gtk_init(nil, nil);
>
> Well, of course. The question is -- should LCL call gtk_init even if
> no gtk functions are called?

Yes, because it is has to parse the command line arguments.
It is the way how a gtk program works. If you don't want a gtk program,
then you must not use the LCL gtk interface.


> Maybe initializing gtk_pixbuf would be enough for TBitmap?

Maybe fpimage is enough for TBitmap.


Mattias

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Marcos Douglas
In reply to this post by Leonardo M. Ramé
On Sun, Mar 20, 2011 at 3:44 PM, Leonardo M. Ramé <[hidden email]> wrote:
>> 2011/3/21 Michael Van Canneyt <[hidden email]>:
>>
>> > Simply said: you can't.
>> > The current TAChart is not suitable for a CGI application. It expects a GUI.
>>
>
> I'm afraid Michael is right.

So, create a GUI app (always on) with HTTP support. The CGI request
charts to this app.

Marcos Douglas

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

michael.vancanneyt
In reply to this post by Mattias Gaertner


On Mon, 21 Mar 2011, Mattias Gaertner wrote:

> On Mon, 21 Mar 2011 21:49:38 +1000
> Alexander Klenin <[hidden email]> wrote:
>
>> On Mon, Mar 21, 2011 at 21:04, Mattias Gaertner
>> <[hidden email]> wrote:
>>> On Mon, 21 Mar 2011 11:25:12 +0100 (CET)
>>> [hidden email] wrote:
>>>
>>> Why?
>>> AFAIK in cgi you can not use the hardware acceleration.
>>
>> Because color manupulation in 16-bit depth may be slower than in 8-bit,
>> and because even withouh acceleration, OS drawing functions may be much
>> better optimized then FPPCanvas ones.
>
> Maybe, maybe not.
> In case of gtk I doubt that *many* functions are much faster.
> In my measurements the difference between 16 vs 8bit was not
> big. It made a big difference if your bitmap is 16bit. I recommend to
> not use the default fp memory image. Writing a 8bit is easy. It would
> be nice if fpimage would provide some other memory image
> implementations. For example 8bit RGB, RGBA and
> Grayscale.

Good idea, I can easily add these.

Michael.

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Leonardo M. Ramé
In reply to this post by Marcos Douglas
On 2011-03-21 09:43:23 -0300, Marcos Douglas wrote:

> On Sun, Mar 20, 2011 at 3:44 PM, Leonardo M. Ramé <[hidden email]> wrote:
> >> 2011/3/21 Michael Van Canneyt <[hidden email]>:
> >>
> >> > Simply said: you can't.
> >> > The current TAChart is not suitable for a CGI application. It expects a GUI.
> >>
> >
> > I'm afraid Michael is right.
>
> So, create a GUI app (always on) with HTTP support. The CGI request
> charts to this app.
>
> Marcos Douglas

Hi Marcos. In my case I cannot do that, because the app will run on a
headless, no X, server.

--
Leonardo M. Ramé
http://leonardorame.blogspot.com

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin
On Mon, Mar 21, 2011 at 23:19, Leonardo M. Ramé <[hidden email]> wrote:
> On 2011-03-21 09:43:23 -0300, Marcos Douglas wrote:
>> So, create a GUI app (always on) with HTTP support. The CGI request
>> charts to this app.
>>
>> Marcos Douglas
>
> Hi Marcos. In my case I cannot do that, because the app will run on a
> headless, no X, server.

I have implemented initial FPCanvas backend.
Since r29962, nogui demo uses nogui widgetset -- thus, it should not
need GTK anymore.
Please test.

--
Alexander S. Klenin

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Alexander Klenin
In reply to this post by michael.vancanneyt
On Mon, Mar 21, 2011 at 22:08,  <[hidden email]> wrote:

>> For starters, the absence of following is most problematic:
>>
>> Canvas.FillRect
>> Canvas.RadialPie
>> Font.Orientation
>
> FillRect and RadialPie can be solved easily. The Font.Orientation can be
> added as a property, I would have to look at FreeType to see how it can be
> implemented. Consider it on the todo list. I can add the missing
> properties/methods quickly, their implementations may take slightly longer
> :-)

Yes, please at least add dummy Orientation property.
Unfortunately, I have to keep compatibility with FPC 2.4.2 until at least
the next Lazarus release, but at least there will be  hope ;-)

I have implemented FPCanvas back-end, (see nogui demo since r29966),
and found the following additional problems:
1) TextSize/TextOut do not work at all (raise ENotImplemented).
2) Clipping is broken (try uncommenting a line after FIXME and see the result)
3) FPCanvasHelper.Assign not implemented -- there exist
  DoCopyProps procedure which does the same, but is protected for some reason.
4) Ploygon/Polyline interface is weaker than in TCanvas,
  and so may require extra array copying
5) TFPImageCanvas has abstract methods(!).
Even standard drawing.pp demo from the fcl-image/examples gives warnings.

--
Alexander S. Klenin

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

michael.vancanneyt


On Tue, 22 Mar 2011, Alexander Klenin wrote:

> On Mon, Mar 21, 2011 at 22:08,  <[hidden email]> wrote:
>>> For starters, the absence of following is most problematic:
>>>
>>> Canvas.FillRect
>>> Canvas.RadialPie
>>> Font.Orientation
>>
>> FillRect and RadialPie can be solved easily. The Font.Orientation can be
>> added as a property, I would have to look at FreeType to see how it can be
>> implemented. Consider it on the todo list. I can add the missing
>> properties/methods quickly, their implementations may take slightly longer
>> :-)
>
> Yes, please at least add dummy Orientation property.
> Unfortunately, I have tokeep compatibility with FPC 2.4.2 until at least
> the next Lazarus release, but at least there will be  hope ;-)

I have implemented FillRect. RadialPie is added but not yet functional.
I also added PolyBezier, but it is not yet functional.

> I have implemented FPCanvas back-end, (see nogui demo since r29966),
> and found the following additional problems:
> 1) TextSize/TextOut do not work at all (raise ENotImplemented).
> 2) Clipping is broken (try uncommenting a line after FIXME and see the result)
> 3) FPCanvasHelper.Assign not implemented -- there exist
>  DoCopyProps procedure which does the same, but is protected for some reason.

I will look at this.

> 4) Ploygon/Polyline interface is weaker than in TCanvas,
>  and so may require extra array copying
> 5) TFPImageCanvas has abstract methods(!).
> Even standard drawing.pp demo from the fcl-image/examples gives warnings.

I will look at this as well :-)

Michael.

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Get JPEG from TAChart in CGI app

Leonardo M. Ramé
In reply to this post by Alexander Klenin
On 2011-03-21 23:49:36 +1000, Alexander Klenin wrote:

> On Mon, Mar 21, 2011 at 23:19, Leonardo M. Ramé <[hidden email]> wrote:
> > On 2011-03-21 09:43:23 -0300, Marcos Douglas wrote:
> >> So, create a GUI app (always on) with HTTP support. The CGI request
> >> charts to this app.
> >>
> >> Marcos Douglas
> >
> > Hi Marcos. In my case I cannot do that, because the app will run on a
> > headless, no X, server.
>
> I have implemented initial FPCanvas backend.
> Since r29962, nogui demo uses nogui widgetset -- thus, it should not
> need GTK anymore.
> Please test.
>

It seems to work, at least from command line, no fonts of course, but
graphics and colors works ok.

I'll test the CGI app from home when I'll go back from work.

--
Leonardo M. Ramé
http://leonardorame.blogspot.com

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
123