On Mon, 21 Mar 2011 11:25:12 +0100 (CET) [email protected] 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 [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
