Mattias Gaertner wrote:
On Mon, 05 Feb 2007 09:19:28 -0300
Luiz Americo Pereira Camara <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
On Sun, 04 Feb 2007 22:28:19 -0200
Luiz Americo <[EMAIL PROTECTED]> wrote:
Mattias Gaertner escreveu:
I started a new thread, because this has nothing to do with the
decision QuickDraw or Quartz.
On Sun, 4 Feb 2007 21:21:15 +0100
"Pieter Valentijn" <[EMAIL PROTECTED]> wrote:
Is there is no scanline function in the bitmap object of Lazarus.
No. At the moment you have to use a TLazIntfImage. See below.
Is there no way we can get access to the raw data?
Short answer:
Yes, but not platform independent, so it is not part of
TBitmap.
Long answer:
1. The TBitmap properties describe only the WinAPI formats. They
are not enough sufficient for the various image formats of the
other widgetsets. TBitmap needs a TRawImageDescription or a
TLazIntfImage. So, Delphi code using TBitmap.ScanLine must still
be extended to work with the LCL in general.
2. Not every widgetset supports a direct pointer to the image.
Some could be hacked to get it. Some images are not stored in the
memory of the application (e.g. on graphic card or on a remote
machine). Sometimes you can tell the widgetset to move the image
into local memory, but this costs performance.
So, it is possible to add a LCL function to return if a direct
image pointer is available and a second function to return the
direct image pointer plus a TRawImageDescription.
Then we could extend TLazIntfImage: At the moment it always
fetches a copy, which is expensive if you do only small changes.
With the above two functions, it could be extended to work
directly on the original image.
Conclusion: I guess, the LCL TBitmap will never have a ScanLine
function that is Delphi compatible, but we could/should provide
more functions for direct access.
This leads for some questions:
I am porting a Delphi component that uses the follwowing sequence:
- Get a HBITMAP with GetCurrentObject(DC, OBJ_BITMAP);
- Get a TDIBSection with GetObject
- Uses TDIBSection.dsBm.bmBits to manipulate the image
Use
http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Taking_a_screenshot_of_the_screen
Thanks
The missing function in LCL is GetCurrentObject. Under windows the
implementation is straighforward. Under gtk is also simple and i
was thinking of implementing it.
How do you want to implement it under gtk?
Getting TDeviceContext.Current* fields of the DC.
Something like.
case uObjectType of
OBJ_BITMAP: Result:= TDeviceContext(DC).CurrentBitmap
etc
Of course with the usual checks.
This gives you the gdk bitmap/image, but how do you get bmBits?
bmBits is get in GetObject function. This is the sequence the api is
supposed to work: you get the the Obj handle through GetCurrentObject
and than use this handle in GetObject to retrieve the info .
Implementing GetCurrentObject is not the problem. The problem is find a
way to implement GetObject.
But the problem is that under gtk,
GetObject (for a bitmap) always returns nil in
TDIBSection.dsBm.bmBits not to say that other fields are also not
set.
So questions are:
- Is viable to get this information (TDIBSection) under gtk? and
others widgetsets?
Every platform has something like it, but incompatible to WinAPI.
For example TDIBSection uses tagBITMAP, which lacks information
about endianess and orientation.
But even if TDIBSection does not have complete information i think it
should be implemented (at least tried) because the LCL provides the
GetObject function, and if not it should be clearly marked as
deprecated to avoid problems when converting Delphi code. Anyway, I
will look if is viable to get the TDIBSection of a bitmap under gtk.
In general: all LCLIntf functions exists only to make porting
Delphi code easier, not to emulate WinAPI. The Wiki mentions several
times, that those functions do not work completely the same as the
WinAPI functions and that they depend on the widgetset.
It is not recommended to use them. We must document for each function,
which parameters are supported.
I want to make clear that i dont think that the winapi should be
emulated in a strict way. What i think that has to be done is 1) Try to
find a reasonable way to implement the api. 2) If there's no reasonable
cross platform way of doing so, document it 3) provides a alternate api
to do the same or at least similar.
In this way, i'm documenting all the differences/problems i'm finding
while porting from Delphi and making a database of it.
About TDIBSection:
AFAIK this is almost only used by speed optimized code. If we emulate
TDIBSection under other widgetsets, they will be slow and hence not
usable.
Agree. I still not investigated how to implement but be sure that i will
only propose a code if is fast and not requires changes in the LCL
I agree, that we need functions for direct access, but TDIBSection is
not sufficient for this. See my other mail about the two needed
functions.
This goes in the direction of what i think. I'll just try step 1. If
fail will not be the end of world.
- Should LCL programs rely in GetObject, SelectObject functions
for cross platform?
No.
- Should i implement GetCurrentObject?
IMO it would be better to improve TBitmap.
Ok. But i'd like at least try to find a correct implementation of
GetObject
It is quite possible for font, pen, brush. But bitmaps are
speed critical, so emulation is no choice here.
See above
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
