[fpc-pascal]Re: working with bitmaps

Mon Oct 20 12:33:04 CEST 2003

I succeed to compile pasjpeg with -dWindows compiler option in Linux and
few changes in sources :)

Pavel Kanzelsberger

On Mon, 2003-10-20 at 12:12, Marco van de Voort wrote:
> > On Mon, 20 Oct 2003, Marco van de Voort wrote:
> > | > a.) this new FPC classes (again) will not use this libraries but do all
> > | >     this data fiddleing together by themselves. :-/
> > | > b.) be therefore much more unstable because the self-knitted code has to
> > | >     be tested again, what is already finished with this C libraries.
> > |      (headers also need testing)
> > |
> > |   c.) keeps the dependancies down.
> > 
> > Possibly you are right.  But it helps nothing when dependences are kept such
> > low that there exists only some trivial sub-sets but nothing useful. Wouldn't
> > it be better to supply something basic which is working in poorest
> > environments before doing something high sophisticated?
> 
> We usually depend on extern initiatives. We can only choose to integrate it
> with the core distro, or refer to the contributed units page.
> 
> > | We only have the tool that was used for the windows unit translation.
> > 
> > Wrong OS. I only develop for Linux.
> 
> I for FreeBSD. Problem is that Unix headers are dirtier than Microsoft
> headers, they use more macro's, and an awfully large amount of conditional
> code. Michael succeed in a libc translation recently.
> 
> > | > Mostly required will be those functions which reading/writing images
> > | > from/to files and putting them somewhere unpacked into memory for further
> > | > manipulation, but even this is not really available.
> > |
> > | There is pasjpg, there is a libpng header, some bmp fiddling.
> > 
> > Great.  'pasjpg' does not even compile on Linux. And as you already said:
> > There is some **fiddleing**, but nothing of it is really useful. Some
> > strength should be made here to build/extend the graphics unit (or add
> > another unit, let's say "imagefile", which should allow and supply a
> > standardized set of procedures/functions for both: Windoze and Linux.
> > Nothing in OOP/CLASS style, only very basic functions which can also be
> > used/embedded later within/into Delphi style classes, but they must work
> > procedural, too.
> 
> When you've  made this, please add it to the contributed units page, and maintain
> it. Preferably support multiple OSes.
> 
> The core team is chronically short on manpower, and has no time for an
> active role in this kind of sideways related stuff if we want to release 2.0
> this decade.
> 
> > TIFF, ... in all flavours. I am sure they are not supported directly, because
> > there are so many minor variations and therefore it is very complicated. So
> > why not offer interfaces which act as wrappers to standard libjpeg.so
> > libtiff.so, .... instead?
> 
> We didn't get them submitted. 
> 
> > Most C programs interface with these libraries, so they should be
> > relatively standard. Isn't it? So it would save a lot of work when a
> > wrapper is made, instead of re-inventing not the wheel, but the complete
> > car.
>  
> The "reinventing the wheel" phrase is the most overused phrase in IT, please
> don't fall for that trap. 
> 
> In the real world, taking a new part is easier than fixing the old. Why would
> it be different in IT ? :-)
>  
> > I decided to develop in Pascal at CP/M times, because this gave me the
> > possibility to write programs without any need to do low-level things. At DOS
> > this continued and allowed simple graphics, too. The logical next step would
> > be that the same should be available on Linux, too, and there FPC is my
> > "TurboPascal for Linux".
> 
> It is. There are some things lacking (personally I would like to see the
> textmode IDE get a new maintainer and see it make fundamental progress), but
> all are manpower related.
> 
> It is not that we don't know these things. However we have to make choices,
> and that means that some things will end up at the bottom line of a A0 format
> to-do list. We make these choices based on 7 years day-in day-out experience
> with the project AND our own needs.
> 
> > Some years ago I had the hope that FPC would become a 100% replacement for
> > TP/BP for DOS/LINUX/..., where I could do basically the same on every
> > platform without any code modification. But I still see that Linux is not very
> > well supported in some parts, especially graphics.
> 
> Like everywhere, most users (and so contributions) focus on the GUI. 
> Lazarus is quite far on *nix. 
> 
> > Why is there still no graph-unit available which does the same as TP.GRAPH
> > /DOS? 
> 
> A combination of being not directly needed for the core system and not getting
> external submissions. 
> 
> > Is it really such complicated to make some code into the graph unit which
> > opens one X11-Window and paints there as a DOS program paints on a VGA
> > screen?
> 
> I don't know, but I think using a widget set (GTK) would be easier. Trying
> it yourself is the easiest way of answering this.
> 
> > I hear the answers in advance: This will not be satisfying, this
> > is causing dependices, ... -- Ok, but X11 is a standard on any graphical
> > Unix.
> 
> Yes, but "graph" is a console program. OTOH win32 also uses the GUI
> subsystem for graph. So I guess the lack of submissions remains
> as cause again.
> 
> > And there is still some option to possibly allow to choose between using
> > X11 and some kind of svgalib for direct access to the graphics card. 
> 
> There is no problem if we had a unit as you described. I don't have 
> a fundamental grudge about a X11 dependancy. 
> 
> Except maybe that I'd reserve the "unit graph" unitname for the most
> compatible and generic one. But there is no such choise to make since
> we don't have multiple TP compatible Linux graph units. 
> 
> > I do not want to start now with low-level things to be able to do simplest
> > things which were absolutely no problem with TP/BP. It is hard enough to
> > accept that even the graph unit is not existing to me, because it does not
> > work on Linux, and I see that FPC goes more and more into a direction which
> > does not make life very easy.
> 
> The problem is that FPC is mainly driven by a couple core developpers, and
> an crowd of 10-30 people that regularly submit bugs, units and/or made and
> maintain FPC packages on the contributed units page. (which I always call
> the "outer core" by myself). And of course there is lazarus.
> 
> We don't have fulltime employees like some linux distributions and projects,
> and no thousands of submitters like the larger volunteer driven Open Source
> projects. This is not a FPC problem. All middlesize projects suffer from
> this. (too little people with long term commitments)
> 
> The core's  schedule is pretty full, they are all volunteers, so they work
> on what they need themselves, or what they see as really hard needed
> improvements. If you want to see what happened to the core system after 1.0,
> see http://www.freepascal.org/future.html
> 
> For the rest we rely on external submissions, which are
> (except from that wellknown longterm bug and code submitting "outer core",
> most of which are regulars on this list) low to very low.
> 
> If you want change, a constructive way would be to create it and submit it.
> 
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
-- 
Secundum Artem - www.pixel32.sk
E-Mail: kanzels at boxnetwork.sk
Phone: +421-905-462611
ICQ: 20990633