Recent

Author Topic: Backwards compatibiliy broken (again)  (Read 20589 times)

LuizAmérico

  • Sr. Member
  • ****
  • Posts: 458
Re: Backwards compatibiliy broken (again)
« Reply #15 on: January 04, 2010, 02:13:56 am »
Hi,

To understand the meaning of this package is necessary to know the history behind it.

When i started the (new) port of VirtualTreeView, a 30kb piece of code that explores at maximum Delphi/winapi, i decided initially to remove the minimum of code necessary to make work so i wrote DelphiCompat that is simply a wrapper around winapi functions that does not exist (at that time) in LCL. This makes possible to get working under win32 faster.

As soon as i started to port to Gtk i found some bugs and started implementing the missing functions or creating workarounds. So there's a reason for each one:

OptimalPixelFormat: VTV requires 32bit bitmaps (pf32bit) to do alpha blending. But under Gtk is not possible to BitBlt a pf32bit bitmap on a 24bit or 16bit screen (http://bugs.freepascal.org/view.php?id=8553). This is my solution to not loose the alpha blending on not 32bit screens under win32 (pfDevice <> pf32bit) and at the same time working on non win32.

Also i found that some LCL features were not implemented yet like creating a mask for a bitmap so the reason for CreateBitmapMask (it would have the benefit of being a one pass process but there are some technical reasons why it can't be a generic approach). Now that is implemented in LCL i switched the code that was using it use TBitmap.Mask instead.

Even some LCL equivalents to winapi was not working correctly even in win32, so the reason for DrawFrameEdge (already fixed). This same function until recently was crashing on gtk (http://bugs.freepascal.org/view.php?id=9234). Some other functions were added or fixed in LCL at the mean time like FrameRect and *MapMode

OSSupportsUTF16 is used in ATBinHEX that cannot be converted to UTF-8. I don't remember where is used exactly.

DirectMaskBlt is just an win32 specific performance optimization where i know in advance that is not necessary to check the alpha channel.

All those limitations were reported to LCL. See http://bugs.freepascal.org/view_all_set.php?type=1&temporary=y&reporter_id=34

In summary this package is intended to give to developers that are porting code from Delphi (mostly me) a bridge to get the port done while the bug/feature is not fixed/implemented in LCL and to slowly replace the functions too win32 specific by LCL ones.

I never intended to create a full working library so did not ask for merging into LCL or advertised much.

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #16 on: January 04, 2010, 11:11:51 am »
Hi,

To understand the meaning of this package is necessary to know the history behind it.

When i started the (new) port of VirtualTreeView, a 30kb piece of code that explores at maximum Delphi/winapi, i decided initially to remove the minimum of code necessary to make work so i wrote DelphiCompat that is simply a wrapper around winapi functions that does not exist (at that time) in LCL. This makes possible to get working under win32 faster.

This is exact the reason why I added the winapi functions when porting SynEdit. I'll add those missing functions.

Quote
As soon as i started to port to Gtk i found some bugs and started implementing the missing functions or creating workarounds. So there's a reason for each one:

OptimalPixelFormat: VTV requires 32bit bitmaps (pf32bit) to do alpha blending. But under Gtk is not possible to BitBlt a pf32bit bitmap on a 24bit or 16bit screen (http://bugs.freepascal.org/view.php?id=8553). This is my solution to not loose the alpha blending on not 32bit screens under win32 (pfDevice <> pf32bit) and at the same time working on non win32.

It is only a temp solution, the final solution will be alpha support on gtk too, so this is not really needed.

Quote
Also i found that some LCL features were not implemented yet like creating a mask for a bitmap so the reason for CreateBitmapMask (it would have the benefit of being a one pass process but there are some technical reasons why it can't be a generic approach). Now that is implemented in LCL i switched the code that was using it use TBitmap.Mask instead.
:)

Quote
Even some LCL equivalents to winapi was not working correctly even in win32, so the reason for DrawFrameEdge (already fixed). This same function until recently was crashing on gtk (http://bugs.freepascal.org/view.php?id=9234). Some other functions were added or fixed in LCL at the mean time like FrameRect and *MapMode

I'll skip those

Quote
OSSupportsUTF16 is used in ATBinHEX that cannot be converted to UTF-8. I don't remember where is used exactly.

It is more that this is not a widgetset issue, but an OS issue.

Quote
DirectMaskBlt is just an win32 specific performance optimization where i know in advance that is not necessary to check the alpha channel.

I don't like to maintain duplicate code. But I might "enhance" the DC so it knows it has a alpha channel or not.

Quote
All those limitations were reported to LCL. See http://bugs.freepascal.org/view_all_set.php?type=1&temporary=y&reporter_id=34

In summary this package is intended to give to developers that are porting code from Delphi (mostly me) a bridge to get the port done while the bug/feature is not fixed/implemented in LCL and to slowly replace the functions too win32 specific by LCL ones.

I don't question the package, I see its needs. But the problem is that it hooks into some LCL internals, so as soon as they are changed ppl will get errors. Thats a second reason I want to add it to the LCL

//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

LuizAmérico

  • Sr. Member
  • ****
  • Posts: 458
Re: Backwards compatibiliy broken (again)
« Reply #17 on: January 04, 2010, 12:51:09 pm »
Quote
I'll add those missing functions.
If you mean add all DelphiCompat functions to LCL be aware that some functions are too win32 specific or the implementation is not doable like ImageList_DragShowNolock or CopyImage. Those are a temporary solution while the component switches to LCL solutions. BTW: many of that functions are not used anymore in VTV.

Quote
It is only a temp solution, the final solution will be alpha support on gtk too, so this is not really needed.

True.
Many Delphi controls use this approach to do alpha blending and even when alpha blending is implemented in LCL this will give the dev some time before he(she) switches to the LCL approach.

BTW: i implemented basic alpha blending (filling a rect with an alpha color) in gtk, gtk2 and qt. This should really be an valuable addition to LCLExt or LCL itself but the problem i face here is that the win32 code is licensed under MPL so incompatible with LCLExt or LCL.

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #18 on: January 05, 2010, 01:25:46 am »
Quote
I'll add those missing functions.
If you mean add all DelphiCompat functions to LCL be aware that some functions are too win32 specific or the implementation is not doable like ImageList_DragShowNolock or CopyImage. Those are a temporary solution while the component switches to LCL solutions. BTW: many of that functions are not used anymore in VTV.

It's not my first time ;)
And I'll add most of them one by one

Quote
Quote
It is only a temp solution, the final solution will be alpha support on gtk too, so this is not really needed.

True.
Many Delphi controls use this approach to do alpha blending and even when alpha blending is implemented in LCL this will give the dev some time before he(she) switches to the LCL approach.

BTW: i implemented basic alpha blending (filling a rect with an alpha color) in gtk, gtk2 and qt. This should really be an valuable addition to LCLExt or LCL itself but the problem i face here is that the win32 code is licensed under MPL so incompatible with LCLExt or LCL.

In this case I try to go native

//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

DonaldShimoda

  • Jr. Member
  • **
  • Posts: 89
    • Parallel Pascal Worlds
Re: Backwards compatibiliy broken (again)
« Reply #19 on: June 06, 2010, 10:47:12 pm »

Luiz, the actual state for virtual treeview new from svn in lazarus ccr is not compile. Can it be because theres part of your code inside lazarus trunk? I dont know if i must install your package or wait it is inside lazarus.

TIA