On Thu, 25 Aug 2005 11:25:12 +1000
Mat Ballard <[EMAIL PROTECTED]> wrote:
> g'day Mattias,
>
> re:
> I have written a graphics app (in D3 for display/render design) that
> heavily depends on large bitmaps.
> ...
>
> Anybody doing graphics out there?
>
>
> i have a very serious graphs app, or set of apps, and am watching
> progress of Lazarus very closely. in the long run, i will need to go to
> 64 bit. however, for speed reasons, it makes major use of
> TBitmap.Scanline - so i face a very major porting problem unless and
> until this is implemented.
>
> Well, we can implement TBitmap.ScanLine by automatically creating a
> TLazIntfImage. Of course this needs some bookkeeping to reduce the update
> between the TLazIntfImage and the Handle.
> Delphi code accessing this ScanLine will probably work with only a few
> changes under windows and maybe a few Linux Desktops.
>
> Would that be sufficient for you?
> that would be pretty damn good, except for below ...
> Of course to get the grade 'runs on Lazarus' you have to enhance the
> Delphi code for the full TRawImage properties and in the end you will
> probably using TLazIntfImage.Pixels. And of course your code can not be
> used easily by fpImage in server applications.
> server applications is the eventual goal: the general design is a
> library of very specialized graphics function, which have several
> different front-ends for different purposes - one of which is a web
> service (others are GUI, one is command line). i take it that
> TLazIntfImage has the same X-dependence issues on Linux as did TBitmap
> did under Kylix ?
>
> the principal issue for me is that we would eventually like to handle
> extremely large bitmaps - eg: A3 size at 2400 dpi. this neccessitates a
> 64-bit migration path. Linux is preferred, but not mandatory, as a server
> OS.
>
> my own thinking was to carefully watch the evolution of Lazarus, and to
> see whether it would be better to: Hack TLazIntfImage to create a Scanline
> property for the chosen OS - lots of {$IFDEF }ing; Rewrite the graphics
> library to use TLazIntfImage; Rewrite the graphics library to use the GD
> Library; Port Theo Lustenberger's TXLBitmap
> (http://www.theo.ch/kylix/webcgi.png) then rewrite the graphics library to
> use it. it can be downloaded from http://www.theo.ch/kylix/XLship.zip. the
> discussion for this can be found at: http://tinyurl.com/9jw4a naturally,
> many issues come into the decision. for example, if Borland pulled their
> finger out and made Delphi64, it would be a no-brainer.
Current situation for lazarus/fpc:
- 64bit: Several people have improved Lazarus for 64bit, but afaik it is not
complete. I have no 64bit machine to test, so I can't help here much.
- TLazIntfImage is the LCL connection to the FPImage units. FPImage is
platform independent designed, supports gui and non-gui (e.g. cgi, console)
applications and provides image, canvas, fonts, pens, brushes, reader and
writer classes. It already supports many common image formats and new
readers/writers are easy to write. FPImage supports 4x16bit (red, green,
blue, alpha).
- Every reader you write for FPImage can be used by Lazarus. Creating a
TBitmap descendent is a matter of a minute. For instance
TPortableNetworkGraphic.
- TLazIntfImage uses the very generic interface of TFPCustomImage and
extends it to support all kinds of real memory layouts of integer rgba
bitmaps: ByteOrder, BitOrder, Color precisions (e.g. 5-6-5), Alignments. It
contains optimized procedures for the most common formats (e.g. 16bit,
24bit, X and windows). No palette support yet.
- Instead of ScanLine you set/get Pixels. This is more intuitive. Of course
with ScanLine you can write faster functions for a few formats. Although the
bmp and xpm reader/writer of the LCL are already faster than GIMP's. So, the
Pixel access is already fast enough for most things you do with the LCL. For
big or many image operations the optimized ScanLine routines can matter and
you will probably work in memory with your own fast format.
- So, with TLazIntfImage you already have ScanLine. You can even access the
whole image. But it is more complex than Delphi's TBitmap.ScanLine, and
that's why we didn't add it yet. If we would add it, people will use their
Delphi code and maybe it will work under windows. Then they go to other
platforms and boom. That's what lazarus should avoid.
- In the devel list we are talking about the possibility to automatically
convert pf32bit and pf24bit Delphi scanline formats to the real format on
the fly. This would allow people to use their Delphi code. But the speed
gain of using ScanLine would be gone.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
