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? > >> 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. 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. 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. > >> - 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. Mattias _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
