I am happy to announce that I uploaded the first version of High-DPI TImageList. The LCL part should be complete, the win32 part as well. There is one backwards compatibility issue: adding sprites - their support is broken (the image is added as one and not cut into several images). I haven't done the design-time part yet either. That means that the ImageList dialog doesn't support multiple resolutions. But everything else should be good.

+ Good news: I was able to add interpolation support with alpha chanel (did you know FPC supports it? :) ) !!! So images are scaled smoothly and nicely without any external library evolved - and it is supported on all OS/WS. Obviously scaling down works better than scaling up.

For now I tested Win32 only - other widgetsets will be probably broken. I'll take a look into them later.

Issue report with a test project:
https://bugs.freepascal.org/view.php?id=32967
Branch to test:
https://svn.freepascal.org/svn/lazarus/branches/HiDPIImageList

Please test and comment - especially component vendors.

To take advantage of the new PPI features in your control you have to
replace all ImgList.Width, ImgList.Height, ImgList.Draw* etc. methods
with PPI-aware properties/constructs. Like:
ImgList.Width -> ImgList.WidthForImagePPI[DesiredWidthAt96PPI,
Font.PixelsPerInch]
- or -
ImgResolution := ImgList.ResolutionForImagePPI[DesiredWidthAt96PPI,
Font.PixelsPerInch];
ImgResolution := ImgList.Resolution[DesiredWidthRegardlessOfPPI];
ImageWidth := ImgResolution.Width;
ImageHeight := ImgResolution.Height;
ImgResolution.Draw(...);
ImgResolution.GetBitmap(...);

etc.

Ondrej

And the screenshots of a LCL application at 100% and 150%. -------------- next part --------------
A non-text attachment was scrubbed...
Name: HiDPIImageList-150.png
Type: image/png
Size: 22134 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180110/81cd7a53/attachment-0002.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: HiDPIImageList-100.png
Type: image/png
Size: 12141 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180110/81cd7a53/attachment-0003.png>

I added Qt, Qt5 and Gtk2 support. I also rewrote the IDE ImageList editor to support multiple resolutions.

Ondrej

I merged the High-DPI (multi-resolution) ImageList into trunk. I'll document the changes in http://wiki.lazarus.freepascal.org/TImageList soon (tomorrow) and also in
http://wiki.freepascal.org/Lazarus_1.10.0_release_notes

Ondrej

With trunk my application now gives lots of tracebacks when using the main menu, which has some images set, though not using an imagelist:

ERROR in LCL: TGtk2WidgetSet.CreateBitmapFromRawImage Incompatible BitsPerPixel
Creating gdb catchable error:

$000000000088BA69 DEBUGLNSTACK, line 731 of lazloggerbase.pas $00000000007788E0 DUMPSTACK, line 1392 of lclproc.pas $0000000000776043 RAISEGDBEXCEPTION, line 860 of lclproc.pas $00000000006EB170 RAWIMAGE_CREATEBITMAPS, line 417 of gtk2/gtk2lclintf.inc
$0000000000787202 RAWIMAGE_CREATEBITMAPS, line 152 of include/lclintf.inc
$00000000008F0FF0 CREATEBITMAPS, line 3633 of intfgraphics.pas $000000000095B362 INSERTMASKED, line 1802 of include/imglist.inc $0000000000958DC1 ADDMASKED, line 1143 of include/imglist.inc $000000000086717C DRAWMENUITEMICON, line 5809 of gtk2

This is using GTK2. Has the implementation of the main menu changed significantly? Unfortunately this is slightly tricky to debug, as the entire desktop freezes.

Colin

Ondrej Pokorny wrote

I merged the High-DPI (multi-resolution) ImageList into trunk. I'll document the changes in http://wiki.lazarus.freepascal.org/TImageList soon (tomorrow) and also in http://wiki.freepascal.org/Lazarus_1.10.0_release_notes

Porting the TurboPower SysTools library to Lazarus, I noticed today (after having updated trunk to contain the new imagelist) that their palette icons no longer have a transparent background. These icons are old-fashioned bmp images with that pseudo-transparency, i.e. one particular color is defined to become transparent. I'll switch to png images anyway, but maybe this bmp transparency issue should be fixed.

Do you use Glyphs in the menu? Anyway, please create a bug report and if possible, attach a sample project to reproduce. Thanks.

The implementation of main menu didn't change significantly, but the image list did change (the menu uses image list internally to store the menu item glyphs). It looks like Gtk2 doesn't like the new AddMasked method.

Ondrej

I do use glyphs on a few of the menu items. Unfortunately a small project with just this doesn't show the error, so a sample project will require some thought.

Colin

I assume it's a specific glyph that doesn't work. Try to add a DebugLn with the menu item name into DRAWMENUITEMICON so that you'll know what menu item and glyph causes it.

Ondrej

Please retest with r57180 (I don't have any components installed that use BMP icons).

Ondrej

Yes, working fine again. Thank you.

I have submitted https://bugs.freepascal.org/view.php?id=33099

It does not show the crash, but it does show some issues. My investigations show that the test program does not crash in the same way as Masked is false for the menu image, whereas it is true in my full program, and I haven't been able to track down why yet.

Colin

Update: I found my main program had some code I had forgotten about that explicitly sets transparent for each menu bitmap:

    MenuItem2.Bitmap.Transparent := True;

and that is why the error is triggered in my main program. (The need to do this may be a bug, but if so it has been present for a long time.)

Colin

The high-DPI imagelist adds a new entry to the lfm file, "BitmapAdv". Is this really absolutely necessary in all cases, for example if the imagelist contains only standard-resolution images? The problem is that once a form with an image list has been opened by Laz trunk it cannot be opened by Laz 1.8 or older any more without an error message and the need to remove this new entry.  In particular, this is an issue for third-party components where the author must be very careful to save demo forms with Laz 1.8, not with trunk.

I remember I had the same argument with the addition of "Application.Scaled := true" to the lpr file, but here portability could kept by putting it into an {$if lclversion >= 1090000} directive. In the lfm files, however, such directives are not allowed.

No, it's not needed if no extra resolutions are stored. I'll check if it can be omitted (it's a manually added entry and not a normal property). If not, I'll add an ignore entry for 1.8.2.

Ondrej

Il 05/02/2018 16:01, Ondrej Pokorny via Lazarus ha scritto:

No, it's not needed if no extra resolutions are stored. I'll check if it can be omitted (it's a manually added entry and not a normal property). If not, I'll add an ignore entry for 1.8.2.

In the past undefined properties were silently ignored when streaming the lfm files. This did provide a good backward compatibility for new properties. Of course using them in code would raise an error, but code can easily be edited, while manually editing lfm files is rather cumbersome. Wouldn't it be good to revive the old way? Or maybe just issue a warning?

Giuliano

I just opened my image list example
(trunk\examples\imagelist_highdpi_designtime\) in Lazarus 1.6 without any problems. I only had to skip some warning boxes:

I hit on "Continue loading" every time and the project opened without problems and no lost properties and I was able to compile and run it (of course without the new high dpi features introduced in 1.9).

=> I cannot confirm that a 1.9 project using the high-dpi image list cannot be opened in 1.8 and older. Just on the contrary - no problem here, only one read error box have to be skipped.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180205/c54fc25d/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: kkaenfnmleaannld.png
Type: image/png
Size: 4675 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180205/c54fc25d/attachment.png>

Whenever I see this dialog I go crazy. I never know which button to press, there's a 67% chance to hit the wrong one. The labels texts are not am absolutely sure that a user less
experienced than me will have the same issues and give up.

It really would be much better to not see this dialog.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180205/d3815eca/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: kkaenfnmleaannld.png
Type: image/png
Size: 4675 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180205/d3815eca/attachment-0001.png>

On Mon, Feb 5, 2018 at 8:04 PM, Werner Pamler via Lazarus <

wrote:

I feel the same about this dialog.
To me it is totally unclear what "Continue loading" means. Every encouter I had with this dialog so far, resulted in either not being able to open the project, or an empy form, which when built and run immediately error'd out.

A dialog that said "skip/ignore this property" and/or "skip/ignore this component" (and then doing what it said) would make more sense. As it is now, when I see this dialog, I just cancel, quit Lazarus and edit the .lfm manually.

Bart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180205/3df8406d/attachment.html>

AFAIK it's not forbidden to improve the dialog if you find it unclear :)

You can even take use of the new TTaskDialog I introduced in 1.7: http://wiki.freepascal.org/TTaskDialog.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180206/5b3af5f7/attachment.html>

Werner Pamler wrote

The high-DPI imagelist adds a new entry to the lfm file, "BitmapAdv". Is this really absolutely necessary in all cases, for example if the imagelist contains only standard-resolution images?

Fixed.

The problem is that once a form with an image list has been opened by Laz trunk it cannot be opened by Laz 1.8 or older any more without an error message and the need to remove this new entry.

Feel free to improve the dialog.

In particular, this is an issue for third-party components where the author must be very careful to save demo forms with Laz 1.8, not with trunk.

Lazarus is perfectly backwards compatible. E.g. If you want to support 1.6, write your demos in 1.6 -> 1.8 and 1.9 will open your project without problems.

Ondrej

Nevertheless ir was a bug that BitmapAdv was streamed even if not needed. Thanks for reporting :)

Ondrej

Ondrej Pokorny wrote

Lazarus is perfectly backwards compatible. E.g. If you want to support 1.6, write your demos in 1.6 -> 1.8 and 1.9 will open your project without problems.

This is correct. But unrealistic. Even if I write a demo for 1.8 I must test it with trunk. And if I commit it after I saved it with trunk without having gone back to 1.8 the new property is in the lfm - the user will see it and get the impression "what piece of crap!". Of course, you will say: don't do this, always run the last test with the release version. But that's the way things are, they just happen, we're only human. But if an unneeded property is not written to the form by trunk, at least this kind of error cannot happen.

Hi, I have a component BGRAImageList that fixes basically the alpha channels of the regular ImageList on Linux using BGRABitmap.

I did not code that component, but I'm the one that updates the package.

Sources:
https://github.com/bgrabitmap/bgracontrols/blob/master/bgraimagelist.pas

It works fine in 1.8, but in trunk there are changes like:

1.8
TCustomImageList = class(TLCLReferenceComponent)

1.9 is TCustomImageList = class(TLCLComponent), so the method ReferenceNeeded is not available.

Questions:
- *What does ReferenceNeeded, and if it is necessary on 1.9*.

Another is this:

1.8
procedure Draw(ACanvas: TCanvas; AX, AY, AIndex: Integer; ADrawingStyle:
TDrawingStyle; AImageType: TImageType;
      ADrawEffect: TGraphicsDrawEffect); overload; virtual;
1.9
procedure Draw(ACanvas: TCanvas; AX, AY, AIndex: Integer; ADrawingStyle:
TDrawingStyle; AImageType: TImageType;
      ADrawEffect: TGraphicsDrawEffect); overload;

In 1.9 the virtual was removed and I can't use override anymore.

My question is *if the method still will be called instead of the LCL one in 1.9 without using override*. I know this is a basic of OOP but I need a bit of help because I never use virtual and overload.

Another question: If I remove override to compile in 1.9, what happens in 1.8?

I never use IFDEF LCL_FULLVERSION and don't know how to use it, any chances to have 2 different methods, one with override and other without, one for 1.8 and one for 1.9 or newer?

And the big question:

*Transparency is now or will be fixed on linux, so I don't need this component anymore and I can archive it?*

lainz wrote

My question is *if the method still will be called instead of the LCL one in 1.9 without using override*. I know this is a basic of OOP but I need a bit of help because I never use virtual and overload.

Virtual methods are polymorphic so a caller does not need to know the actual type of an object. The correct virtual / overridden method is always called.
I guess your code knows the exact type (BGRAImageList) and can use it. Thus the correct method is called even if it is not virtual.

Juha

Ok Juha thanks.

And what about the ifdef for that missing method? ReferenceNeeded

Sent from Mailspring (https://link.getmailspring.com/link/local-0739f840-40a8-v1.1.3-27dcee2f at PC-i7/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=lazarus%40lists.lazarus-ide.org), the best free email app for work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180208/791ec811/attachment-0001.html>

TLCLReferenceComponent has a handle.
I have no idea why an ImageList would need a handle. I noticed there is now:
TCustomImageListResolution = class(TLCLReferenceComponent) Maybe Ondrej can explain why it is there.

Juha

First of all, the image list became multi-resolution. You have the new class TCustomImageListResolution that is the new "TCustomImageList". You have to move your custom code there.

On win32 you need a handle for WinAPI native controls. The real imagelist code (along with ReferenceNeeded method) was moved into TCustomImageListResolution.

You have to move all your code into a TCustomImageListResolution descendant and register it in TCustomImageList.GetResolutionClass.

Again, override TCustomImageListResolution.Draw

My question is *if the method still will be called instead of the LCL one in 1.9 without using override*. I know this is a basic of OOP but I need a bit of help because I never use virtual and overload.

Override TCustomImageListResolution.Draw

Another question: If I remove override to compile in 1.9, what happens in 1.8?

The new image list from 1.9 is not compatible with 1.8. You have to release a new version for 1.9+ only.

I didn't change anything about transparency but for me transparency works fine on both Gtk2 and Qt Linux. (I don't know any other details.)

Ondrej

Thanks. If transparency works fine the best should be deprecate the component.

El feb 8, 2018 5:08 PM, "Ondrej Pokorny via Lazarus" <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180208/313de8a2/attachment-0001.html>