Hello,

Out of curiosity:

Are there any plans to make the LCL (and by extension the IDE itself) High-DPI aware? Working on a Macbook Pro with retina screen (running kubuntu) is OK if you only need to edit code, but as soon as you need to use buttons (any toolbutton or even component palette button), it becomes very difficult. The editor toolbar is next to useless on high DPI.

Michael.

I do write High-DPI aware LCL application with Lazarus without problems. The IDE itself should at some point in the future support it as well (IMO by default, without any extension). But I don't know if there are some plans about it.
I haven't bought a 4K display because of High-DPI problems in Delphi and Lazarus IDEs.

Ondrej

I think Graeme's question about storing DPI in .lfm files might be relevant.

As an aside, I've been working on setting up a "cheap" TV as a 3K display for somebody. It's doable, but needs a fairly recent card and end-to-end HDMI.

Would you mind elaborating on this ?

I wrote an app which is DPI aware (as per the instructions on the Lazarus wiki).

It worked on Linux, Windows 7. Then someone ran it on Windows 8 and 10, and those versions of Windows did something which completely messed up the DPI awareness. I believe it has something to do with the manifest, but I didn't have time to investigate it yet :(

Michael.

Mark Morgan Lloyd wrote

I think Graeme's question about storing DPI in .lfm files might be relevant.

That's just the tip of the iceberg - what about multi-head systems where each monitor has a different DPI value. Such system are very easy to setup (and least under Linux or FreeBSD) and quite common - at least in developer circles. So how does LCL's "Screen" or "Application" object report DPI values then?

Regards,
- Graeme -

How does the VCL work on High-DPI?

Mattias

All I know is: It's DPI-Aware. Normally, that should cover most cases. I do not know if it is multi-monitor DPI aware.

To be correct, in early versions of Delphi, DPI-Awareness was severely broken. So much so that we had to disable it in our applications.

Michael.

Michael Van Canneyt wrote

It worked on Linux, Windows 7. Then someone ran it on Windows 8 and 10, and those versions of Windows did something which completely messed up the DPI awareness.

Strange, because using the same method as what you, but with a fpGUI test application. Scaling worked perfectly on Linux, FreeBSD, Win2000, WinXP, Win7 and Win8.1

Here are screenshots I just did under Windows 8.1. The application was designed at 96dpi, and I tested with 120 (120%), 144 (150%) and 192 (200%) dpi values. Note how the whole application stays in proportion with clear text and graphics.

http://geldenhuys.co.uk/~graemeg/temp/

Granted, under Win8.1 I had to include a manifest file to tell Windows that my application is DPI-aware, otherwise it does scaling (app stays at 96dpi and then Windows zooms the app). Here is the manifest file I used, as as recommended by Microsoft.

===========================
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
<asmv3:application>
<asmv3:windowsSettings
xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
===========================

https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266%28v=vs.85%29.aspx

Regards,
- Graeme -

Michael Van Canneyt wrote

All I know is: It's DPI-Aware. Normally, that should cover most cases. I do not know if it is multi-monitor DPI aware.

Delphi 10 Seattle (the IDE) is severely broken - everybody on Google+'s Delphi community is complaining about it. All the IDE dialogs are broken, and Embarcadero has no solution yet. There first attempt at a quick fix was broken too.

I don't know if this link will work, but here it is:

https://plus.google.com/communities/103113685381486591754

I believe your own application will work correctly and VCL is multi-head aware. I don't have Delphi 10 Seattle, so I couldn't test myself.

Regards,
- Graeme -

When I worked with Delphi, VCL's DPI support was broken and a the retailer's support was frustrated when people kept asking about it. I don't know about the latest situation. Maybe FireMonkey has solved it better. Anyway, I think we should solve it despite of how VCL behaves.

In bug tracker there are 9 issues with tag HighDPI. The real number of high DPI issues is much higher. For example this one has many related issue marked :
http://bugs.freepascal.org/view.php?id=14688

Somebody should take initiative. I personally don't know what exactly must be done to fix things.

One important part of HighDPI would be scalable icons. Sandro Cumerlato had an idea of SVG support for LCL and the whole IDE, but I have not heard of him or his plan for a while.
SVG support sounds very good. In fact it is becoming a necessity with all the high resolution gadgets.
I have followed KDE project's development over years. They switched to SVG graphs already > 10 years ago and yes their GUIs look good.

Who would step in and implement SVG support. I believe Sandro would join if there are other people involved.

Regards,
Juha

[...] Who would step in and implement SVG support. I believe Sandro would join if there are other people involved.

There are currently about 400 icons in the IDE.
We need volunteers to create them either as SVG or as higher resolution image.

Mattias

Mattias Gaertner wrote

There are currently about 400 icons in the IDE. We need volunteers to create them either as SVG or as higher resolution image.

What about using a vector format to be (rather) independent of the display resolution (as long as it's not too small).

-Michael

I don't use the designer at all (no LFM files). I create every visual component and form in pascal sources and I manually care for proper scaling. This approach slows down a little bit the design but I have to say that I am very happy with it.
Actually everything I do is that I use a scaling factor for every control I place on the form. Something like:
Button.Width := ScaleMe(100);
Button.Height := ScaleMe(20);
And yes, I use manifest with DPI awarness enabled. Easy and works like a charm. I have not added support for multiple monitors with different DPI yet, though. But this shouldn't be a big problem. You just have to know that the form moved to another screen and scale every control appropriately.

Ondrej

Maybe the V in SVG stands for vector, maybe not.

Mattias

Juha Manninen wrote

One important part of HighDPI would be scalable icons. Sandro Cumerlato had an idea of SVG support for LCL

+1

I fully agree with that. I'm actually busy doing exactly that in fpGUI too. I want the default icon set to be SVG only. AggPas (the new fpGUI graphics backend) has excellent SVG support. AggPas is included with Lazarus too, so that could be used there as well.

On a side note:
I experimented in fpGUI using FontAwesome too - yes, the web technology for scaleable icons. That works very well in fpGUI too. :) Though I still think SVG is the better option.

Regards,
- Graeme -

Mattias Gaertner wrote

There are currently about 400 icons in the IDE. We need volunteers to create them either as SVG or as higher resolution image.

IMO the icons are the latest problem. Personally I don't care if the icons are blurry at higher DPI. It would be absolutely sufficient that every window and control in the IDE is properly scaled and images are resized with quality loss.

Maybe the best solution would be to buy a professional set of icons (via some fund-raising e.g.). I don't think there is a volunteer who would make 400+ icons for Lazarus...

Ondrej

Both VCL and FireMonkey are not automatically DPI aware. In VCL, it is possible with manual approach:
https://community.embarcadero.com/blogs/blog-menu/entry/how-to-guide-upgrading-your-delphi-vcl-applications-to-support-4k-displays (Works pretty well.)

I don't know the state of the art of FireMonkey, though. The last time I checked it was broken. And since FMX should be scalable by design, this was a NO-GO for me. So I switched to LCL :)

Ondrej

Mattias Gaertner wrote

There are currently about 400 icons in the IDE. We need volunteers to create them either as SVG or as higher resolution image.

Use SVG directly and let it render the correct
will solve the problem for any dpi value. Higher resolution images will only solve the problem for hard-coded dpi values like the Microsoft ones... Think Android phones and tables, where every devices has a different DPI value and they vary greatly.

Break it down into manageable steps:

1. Add SVG support to LCL, but keep BMP & PNG support too.
2. Change the high-visibility icons to SVG first.
eg: the ones on the main toolbar.
3. Then as time permits (or contributors help), go through the menus and dialogs one by one.

Regards,
- Graeme -

Ondrej Pokorny wrote

It would be absolutely sufficient that every window and control in the IDE is properly scaled and images are resized with quality loss.

Bad quality icons totally ruin the look of any application. End-users would be pretty darn disappointed as they judge every app visually.

Maybe the best solution would be to buy a professional set of icons (via some fund-raising e.g.). I don't think there is a volunteer who would make 400+ icons for Lazarus...

Just as was done before (a couple years ago), when all Lazarus icons had an overhaul. Nobody expects a single volunteer to do it all. Before we had many people, myself included, chip in and create a few icons at a time. After a couple weeks or months, they were all completed.

Regards,
- Graeme -

Ondrej Pokorny wrote

it is possible with manual approach: https://community.embarcadero.com/blogs/blog-menu/entry/how-to-guide-upgrading-your-delphi-vcl-applications-to-support-4k-displays (Works pretty well.)

OMG - a 38 page guide! Are they joking. I used about 20 lines of source code and my fpGUI apps scale perfectly. The same method (and very similar code) can be applied to LCL too. Bitmap images/icons are the only thing that needs a bit more attention (to keep them sharp), and that is where SVG comes in.

Regards,
- Graeme -

It may be the last problem, but it can be worked on independently, so volunteers can already start.

Maybe the best solution would be to buy a professional set of icons (via some fund-raising e.g.). I don't think there is a volunteer who would make 400+ icons for Lazarus...

Normal icon sets are about common topics. Most Lazarus icons are hard to map to such icons, because they are either about specific graphics (e.g. TDBListBox, TMySql51Connection) or about abstract topics (jump to implementation).
So you need a good deal of custom icons.

Mattias

The document is so big because they provide a lot of background info, they also cover the manifest file etc. Actual code is very little.

It's already outdated, because for Windows 10 you need yet another entry in the manifest file...

Michael.

The manifest file is probably the problem I am facing...

Michael.

What do you think about http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html ?

Regards, - Graeme -

el es

Lukasz Sokol wrote

What do you think about http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html ?

I'm well aware of the fact [issue] that large icons normally use large detail and small icons should use less. But that comes down to the fact of how the designer designs the icons. KDE and Gnome generally show that a single SVG file can suffice - by sacrificing on "intricate details" is the design.

Bottom line - the SVG solution is a lot better that shipping say Lazarus with its 400 icons in 15 different icon resulutions. That ends up with 6000 image files, which is crazy.

I already detest Lazarus's default application icon, which comes in at 140KB - larger than the source code of all my "quick test apps".

Regards,
- Graeme -

Michael Van Canneyt wrote

The document is so big because they provide a lot of background info,

Indeed, I downloaded and scanned the document after I posted my previous message. [then went ahead and studied the PDF internal code generated by wPDF ;-)]

Regards,
- Graeme -

I had seen this article already, which is why I also think that SVG is not the way to go.

Basically, the only excuse for using SVG for icons, is lack of time.

Michael.

Michael Van Canneyt wrote

Basically, the only excuse for using SVG for icons, is lack of time.

They way displays are improving, 16px, 32px graphics will soon go by the way of the DoDo. The smallest resolution images on a 300+dpi (4K plus) display will probably end up being much larger than we see now, so the scaling of image detail should not nearly be as exaggerated as that article implies.

I don't presume to know the details of the SVG file format, but I wouldn't be surprised if it includes some reduced (optional) detail on low resolution rendering. If not yet, then a future extension of the SVG file format. Maybe the issue is simply that not all SVG viewers are created equal - some don't support all the features of a SVG file?

Regards,
- Graeme -

That was explained in the link Lukasz posted.

Mattias

Bottom line - the SVG solution is a lot better that shipping say Lazarus

with its 400 icons in 15 different icon resulutions. That ends up with 6000 image files, which is crazy.

I disagree with you. First we dont need 15 different icon set, just few for every DPI something like Android that for our case it will be about 5 more or less. Second we can use SVG and its better but we can make 2 set one detailed and one simple. Designer will do it simply. Third many icons will not a problem for an IDE.With this way we can run Lazarus even in a mobile or a TV!

So I think after solving DPI aware IDE we can find someone to make new set icon with SVG and PNG export for different situation.

Regards, Ara

Am 07.10.2015 13:30 schrieb "Graeme Geldenhuys" <

: On 2015-10-07 12:09, Lukasz Sokol wrote: > What do you think about

http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html ?

In our company we do the icons for each resolution by hand and it definitely makes a notable difference whether the icon is downscaled from a detailed one or handcrafted with less details.

Bottom line - the SVG solution is a lot better that shipping say Lazarus with its 400 icons in 15 different icon resulutions. That ends up with 6000 image files, which is crazy.

The .ico file format supports multiple resolutions.

I already detest Lazarus's default application icon, which comes in at 140KB - larger than the source code of all my "quick test apps".

On Windows you can only use .ico files for application icons and the default icon is supposed to look good in all zoom levels of the explorer...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151007/5782599c/attachment.html>

Mattias Gaertner wrote

Maybe the V in SVG stands for vector, maybe not.

Right you are:https://en.wikipedia.org/wiki/Scalable_Vector_Graphics

But what I meant was not how the graphics is created but the format stored in the resource to be drawn at run time.

-Michael

stored in the resource to be drawn at run time.

You /do/ know that a part of SVG is also the file format, namely XML? Why invent something new when it's already there...
(And yes, resources can store arbitrary files)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151007/90c09798/attachment.html>

is there not a conversion tool that can convert them from what they are now (raster??) to SVG format?

a quick look shows there's various ways but it seems that many simply embed the original image within the SVG output... the good ones that work seem to be manual (eg: inkscape, adobe illustrator)...

now (raster??) to SVG format?

a quick look shows there's various ways but it seems that many simply

embed the original image within the SVG output... the good ones that work seem to be manual (eg: inkscape, adobe illustrator)...

Yes, there are conversion tools, but that does not necessarily mean that the resulting images are nicely scaleable. It might work, it might not and depending on the algorithms the tool uses it might even depend on the source image...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151007/dcabd7f8/attachment.html>

Sven Barth wrote

(And yes, resources can store arbitrary files)

Sorry. I did not intend implementation details, but just suggest to consider if it would be viable at all to support rendering icons in vector format at runtime in the LCL to be able to better support any need for higher resolution. (Or is that just a silly idea of mine ?)

-Michael

consider if it would be viable at all to support rendering icons in vector format at runtime in the LCL to be able to better support any need for higher resolution. (Or is that just a silly idea of mine ?)

Looking at this thread it seems not to be simply a silly idea of yours and yes, it would be viable. The question however is whether it is desireable (see that link from Lukasz Sokol).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151008/17e88aeb/attachment.html>

Can't help but think (though I haven't seen the SVG spec), does the SVG format have indication of LOD of the elements, and possibly element class (contour, key, background etc), or scaling factor speed, or something like that? so the creator of the image can indicate when to stop showing certain portions of the image... one could do creating it large, then downscaling without loosing the gist of the icon...

Of course it is then on the image creators' head to indicate what needs to stay at different level of details, how 'quickly' the lines should scale relative to the resizing...

(sorry for the offtopic)

Lukasz