Hello,

I have worked on high DPI features recently.

If you want to play with high DPI support, follow this instruction: http://wiki.lazarus.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.7_and_above

For Lazarus IDE itself: Recompile the IDE with LCLScaleForms compiler define before testing Lazarus IDE and reporting/fixing any layout bugs. After some time of testing LCLScaleForms will become default.

Ondrej

Question:
What will happen if I design on a HighDPI system, and then open the project on a 96-DPI system ?

Michael.

Michael Van Canneyt wrote

Question: What will happen if I design on a HighDPI system, and then open the project on a 96-DPI system ?

The forms will be rescaled correctly. I.e. the IDE designer itself is DPI aware.

Ondrej

Will this be so for all forms in the project, or just the form(s) that I opened ? I want to determine whether all forms will be at the same DPI or not.

Michael.

Ondrej Pokorny wrote

The forms will be rescaled correctly. I.e. the IDE designer itself is DPI aware.

Does it now finally store the "designed dpi value" in the *.lfm files (like Kylix did)? Otherwise if I run at 130 dpi and design a form, and somebody else runs at 96 dpi and opens that same designed form (or other way round) it normally means the form is f**ked.

Regards,
Graeme

Michael Van Canneyt wrote

Will this be so for all forms in the project, or just the form(s) that I opened ?

A very good question! Also, what dpi value does the IDE default to, for older projects? Does it always assume the original forms were designed at 96 dpi, or is there a place in Project Options (or a global IDE wide setting) where you can specify the original designed dpi value as a default starting point?

Regards,
Graeme

Michael Van Canneyt wrote

Will this be so for all forms in the project, or just the form(s) that I opened ?

Only the forms you opened.

I want to determine whether all forms will be at the same DPI or not.

No, they will be not. Every form/frame has the property "DesignTimePPI" that stores the value at which the form/frame was designed.

Yes, the property is named DesignTimePPI.

It always defaults to 96 PPI.

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

Good.
Imagine opening a project with 100 forms, and having to wait for all forms to be converted...

Thanks.

Michael.

For Delphi Anreas Hausladen has made a IIDE plugin which opens each form One by One. This would be good feature.

Especially if you have form inheritance (at least in Delphi).

-Tee-

On Fri, Dec 9, 2016 at 11:15 AM, Michael Van Canneyt via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161209/792de6b7/attachment-0001.html>

Tommi Prami wrote

For Delphi Anreas Hausladen has made a IIDE plugin which opens each form One by One. This would be good feature.

Well, we have a project with a couple of thousand forms. We can go and watch a nice movie while the IDE would be doing this :-)

Michael.

Thanks for the good work Ondrej! A big step forward. I will test it in the next few days and hopefully can give some feedback.

Although this is a step forward I think working with pixels is something from the past as with the Sinclair ZX81 (where you have 64x48 pixels) or Commodore 64. (320x200px!) :-) But today's computers still thinking in pixels not in size. And working with just pixels might work if our screens will always be 1024x768 pixels with size of 15".

Erwin

Op 9-12-2016 om 9:12 schreef Ondrej Pokorny via Lazarus:

Looks like Visual Basic was onto something when they defaulted to "twips" back in the 90s :-P

On Fri, Dec 9, 2016 at 12:52 PM, Erwin van den Bosch via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161209/0971008e/attachment.html>

If you want pixel perfect drawing, you have to use pixels :(

Ondrej

Op 9-12-2016 om 12:18 schreef Ondrej Pokorny via Lazarus:

When you introduce DPI of a screen and scaling you lost the pixel perfect drawing too. :(
Example: scaling from 96 to 120 dpi = x 1.25
So 7 px * 1.25 = 8.75 = 9
21 px * 1.25 = 26.25 = 26
22 px * 1.25 = 27.5 = 28
How to get pixel 27?

Erwin

No :)

Easily - use pixel value 27 after scaling.

Ondrej

Op 9-12-2016 om 12:41 schreef Ondrej Pokorny via Lazarus:

I'm sorry, don't getting it. You design on a 96 dpi screen. So you have pixel 20, 21, 22 etc. There is no such thing as pixel 21.5. When you scale you always get rounding errors.

Am I missing something?

Luckily, when everyone has a 4k (or more) screen, nobody can see that you one pixel of. So the non pixel perfect will be a non issue in the upcoming future. :)

Erwin

Erwin van den Bosch wrote

So 7 px * 1.25 = 8.75 = 9 21 px * 1.25 = 26.25 = 26 22 px * 1.25 = 27.5 = 28 How to get pixel 27?

Use a 2D graphics framework like fpGUI does with AggPas, which allows for sub-pixel rendering. ie: renders pixels smaller that 1px by using anti-aliasing, alpha blending and LCD sub-pixel filtering.

Regards,
Graeme

Op 9-12-2016 om 12:56 schreef Graeme Geldenhuys via Lazarus:

That might be the solution! (but you loose some contrast)

Another problem with scaling is the thickness of lines. Example: you are (or a control) drawing lines on a form with a thickness of 1 pixel. If you scale the form from 96 to 192 dpi what to do with the thickness of lines? It should be 2 pixels on a 192 dpi screen to get the same thickness.

Erwin

It would be a nonsence in regard to SVN/Git as well. No chance to send a patch for Lazarus IDE, for example.

Ondrej

Erwin van den Bosch wrote

That might be the solution! (but you loose some contrast)

Only on exact vertical and horizontal lines - if the mid point of the pixel fall of the center point of a screen pixel. On curved or diagonal lines there is no contrast loss, because of anti-aliasing already. If the developers knows he is drawing exact vertical or horizontal lines (eg: the background grid in a graph), the AggPas API has an extra boolean parameter that will grid-fit the line (loosing accuracy, but keeps line sharpness).

I personally prefer accuracy, so don't mind that - the same reason I don't enable font hinting (forcing text to fit a grid) in my desktop environment. I prefer the true shapes of character glyphs - like the font designer intended.

Another problem with scaling is the thickness of lines. Example: you

If you apply scaling, obviously your software needs to apply it to everything. Line thickness, font sizes, image sizes, widget sizes, form sizes etc. I have no idea if the new high DPI feature in Lazarus 1.7 goes into all that detail. It would be interesting to know.

Regards,
Graeme

El 09/12/16 a les 09:12, Ondrej Pokorny via Lazarus ha escrit:

I currently have some projects where I use ScaleBy to manually scale the forms depending on the monitor resolution[*], if I leave tform.scaled to false will it work as before?

[*] it's a multi monitor setup where each form is assigned to a specific monitor, I design at a resolution that I want (usually 2 thirds of my monitor), then I scale it to fit the assigned monitor and make a small copy of the same form to show on the main monitor (where I can see the content of all the other monitors).

Bye

Luca Olivetti wrote

I currently have some projects where I use ScaleBy to manually scale the forms depending on the monitor resolution[*], if I leave tform.scaled to false will it work as before?

Yes, Scaled=False defaults to old behavior. Just make sure you don't start Lazarus IDE in high DPI and design the forms there.

Ondrej

El 09/12/16 a les 16:55, Ondrej Pokorny via Lazarus ha escrit:

But "After some time of testing LCLScaleForms will become default." What happens then when I open an old form or want to design a new one with no automatic scaling?

Bye

Luca Olivetti wrote

But "After some time of testing LCLScaleForms will become default." What happens then when I open an old form

It will have Scaled=True.

or want to design a new one with no automatic scaling?

Set Scaled=False explicitely in the object inspector OR (global solution) compile the LCL with LCLDontScaleForms compiler define. (It will be announced.)

Ondrej

El 09/12/16 a les 17:17, Ondrej Pokorny via Lazarus ha escrit:

But I can change it back to false, right?
And, more important, ScaleBy will work just like before, won't it?

Bye

Please read my previous email to the end.

And, more important, ScaleBy will work just like before, won't it?

Yes.

Btw. do your different monitors really have different DPI settings? To me it looks like you just scale your forms.

ScaleBy works independently on the new Scaled parameter and high DPI features.

Ondrej

El 09/12/16 a les 17:26, Ondrej Pokorny via Lazarus ha escrit:

I probably mis-read it: I though that you could do that only for new forms.

Yes, I don't care about the dpi, I just want the form to fill the whole monitor. ScaleBy works nicely for that

ScaleBy works independently on the new Scaled parameter and high DPI features.

Oh, I thought the former would be the basis for the latter, so that they would be mutually exclusive.

Bye

Hi

Just download latest svn to test this.

Immediate problem, opening current project I get message unknown property DesignTimeDPI so choose continue loading.

My forms load, then get scaled.
I have checked property of form and Scaled is unchecked False; PixelsPerInch=72
DesignTimePPu=72

The scaling makes my form hard to read and even harder to edit; I am using 3rd party controls and some fonts are not scaled.

How can I disable this feature, I have my own scaling routines that manipulate the controls and underlying fonts etc at runtime and scale perfectly, also my scaling routines also auto add extra controls as the screen area increases.

I like the idea for a new project; but I would need this de-activated to continue developing current and previous applications.

Question why are my forms scaling when opening them, even though they were not designed for this feature. This is scarey.

Josh

Josh wrote

Just download latest svn to test this.

Thanks for the feedback!

Immediate problem, opening current project I get message unknown property DesignTimeDPI so choose continue loading.

DesignTimeDPI was published for a short time period (from 1st of December). It's fine to ignore it. People coming from 1.6 won't be affected.

Because your system uses 72 PPI. Unfortunately the IDE uses 96 PPI as default for legacy projects and thus scales it. I see it as major issue and I'll come up with a solution.

Ondrej

Kostas Michalopoulos wrote

Although this is a step forward I think working with pixels is something from the past

It is normal even today, coz we have raster GUI, only in rare cases frameworks do give us the vector graphic. It is GUIs in games.

Does r53623 help you? Forms with Scaled=False shouldn't be automatically scaled in designtime - that was obviously a mistake from myself.

Ondrej

Hi

Just got latest svn 53624, The change does indeed help in that the form in not resized.
However when I compile, I am getting
Project Raised exception class 'EREADError' with message, error reading xxx.designtimedpi: unknow property:'DesignTimeDPI'

This is when compiled with or without debugger, and when app launched directly.

If I click ok/continue a few times; then application is auto terminated.

Does r53623 help you? Forms with Scaled=False shouldn't be automatically scaled in designtime - that was obviously a mistake from myself.

Ondrej

Josh wrote

error reading xxx.designtimedpi: unknow property:'DesignTimeDPI'

Please open and resave the affected forms or delete DesignTimeDPI from all your LFMs and rebuild. Sorry for inconveniences.

Ondrej

Is there any chance to have TApplication property which will disable Scaled (even when Scaled=True) for complete application (Design and RunTime) ?

zeljko

zeljko wrote

Is there any chance to have TApplication property which will disable Scaled (even when Scaled=True) for complete application (Design and RunTime) ?

I thought about it already but I haven't solved one issue: how should that property be reliably read both in design and run time?

We'd need some kind of project option (in .lpi) that would automatically set the corresponding TApplication property in .lpr - something like TApplication.Title (that can be set in project options). I am still not 100% sure about it, but it may be the only one solution. Any suggestions are welcome!

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161210/28a32833/attachment.html>

Ondrej Pokorny wrote

I thought about it already but I haven't solved one issue: how should that property be reliably read both in design and run time?

IMO, runtime is not problem if you implement that property into Application, design time yes, lazarus should manage that somehow,

zeljko

Oh, then we get a global switch to enable/disable high DPI support OS independet (as defined in the Windows manifest - and then this value has to take care about that switch).

Michl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161210/edc515bf/attachment-0001.html>

Michael W. Vogel wrote

Oh, then we get a global switch to enable/disable high DPI support OS independet (as defined in the Windows manifest - and then this value has to take care about that switch).

Nono, these settings have to stay completely independent. As other people wrote recently - they may have developed their own scaling features - in that case they need DPI support ON in the manifest, but built-in LCL DPI support OFF.

Ondrej

Imo, there's no need for big philosophy about this. Application.HiDPI := Off; should be enough for runtime (no need to store this property in lpr/lfm or whatever, just put it after Application.Initialize). In Lazarus options there should be: Enable hiDPI designing (can be true by default if you want), so app design is done in old way and new properties does not influence current projects just like that. Some of us do not plan to switch imediatelly to hiDPI features (Michael already mentioned why is it so), so global on/off is really needed.

zeljko

We share the same opinion :)

I just add that both the runtime and designtime properties should be connected (Application.HiDPI <=> Enable hiDPI designing).

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