DPI and Scaling Discussion

[Lars Fosdal 1792]

It is sad that HighDPI seems so hard to do - regardless of choice of toolbox.

[qubits 20]

Hi Lars,

Thinking I'm noticing the effects of this.

Strange sub par rendering only on noticeable on android.

my android 11 phone has a screen size of 2520x1080

my app reports 916x411 with typical size settings in phone.

changing phone options make everything smaller, can only get 1081X485, so not much of a difference.

everything in my app is created in code.

all sizes and positions are nothing more than division of height and width.

Which I have either rounded/trunc to see it appeases rendering gods.

 

now the interesting, pulled a screenshot off my phone, produced a png which was 2520x1080 72ppi

noticing this I'm thinking my textures are way too small.

 

because currently, the round rectangle, is not round, sad to say.

only android, windows perfect at any res.

other than that, everything is precisely sized and placed, looks really good, so I'm just being picky.

 

So, I'm curious is this DPI and scaling playing with me?

 

Thanks in advance,

Dave

 

[Der schöne Günther 316]

About a year ago, we updated one of our applications from 10.0 Seattle to 10.4 because we had to support HighDPI. I found it much easier than expected and was very pleased with the results.

 

Some people believe all interface glyphs should be vector images instead of rasterized images. But I went with just storing the icons in different sizes and picking the right ones at runtime. All ImageLists were replaced by VirtualIamgeLists (or what they're called). After that, a few minor adjustments were necessary here and there, but not much.

 

Only doing Windows, not sure how the development experience is on other platforms...

Edited January 12, 2022 by Der schöne Günther

[qubits 20]

I make all images and controls at runtime, do store some backgrounds, but only having issues on tbitmaps I make in code.

more dots per inches on the phone, my pics need more pixels.

Multiplying my texture width and height by current screen scale, seemed to fix this up nicely.

Windows has a scale of 1, my android tab a scale of 1 my phone a scale of 2.625

 

got the scale with this.

 

function GetScreenScale: Single;
var ScreenService: IFMXScreenService;
begin
  Result := 1;
  if TPlatformServices.Current.SupportsPlatformService (IFMXScreenService, IInterface(ScreenService)) then
    Result := ScreenService.GetScreenScale;
end;

 

 

Thanks!

 

Dave

[qubits 20]

Now on to the text.

It's also missing pixels only on android, again windows is perfect.

this will a bit more work i see.

text is just a control created at runtime, ttext3d.

so I'm seeing it probably won't work and as I've already removed most of it, time to take it all out as I need to also scale all the text.

been thinking on this for a bit, wondering if I don't just scale everything up, calculate rounded/trunc positions and heights, then scale the whole mess back down and don't trunc or round.

this way, when rendered should be on integers, bet you opengl would like that.

be cool if i could put a TMatrix on my scene, wouldn't have to change anything, save matrix, replace it with a scaled one, do all my work, restore the matrix, all done.

 

 

[Guest]

"High DPI" caused me to do a complete rewrite. Well, it was a major factor anyhow.

Starting from scratch with DevExpress as the foremost library that must handle it, it has worked pretty well.

Bugs are showing up every now and then and since DX has a faster patch-cycle than VCL it has been working.

The thing that still bugs me even though i have started out from 0 with HighDPI enabled toolbox is the time it takes to resize a VCL app compared apps created using other frameworks.

[dummzeuch 1505]

2 hours ago, Dany Marmur said:

The thing that still bugs me [...] is the time it takes to resize a VCL app compared apps created using other frameworks.

By the look of it there are two factors:

1. Every rescaling of a control seems to cause a redraw of the whole form. There should be a way to block redraws until scaling has finished. I tried a few tricks, but none worked so far or had side effects that I didn't like either.

2. Moving a form between monitors with different scale factors often seems to trigger the rescaling multiple times. (That might be a peculiarity of my test program though.)

 

In particular the IDE takes several seconds to rescale. That's really annoying, and I'm glad that I currently don't have to use it for my day work.

 

Btw.: How well does the scaling work with fmx programs?

Edited January 13, 2022 by dummzeuch

[Lajos Juhász 293]

Changing a DPI can also cause the following error message:

---------------------------
Debugger Exception Notification
---------------------------
Project XXXXX.exe raised exception class EReadError with message 'Stream read error'.
---------------------------
Break   Continue   Help   Copy   
---------------------------
 

With call stack: 

 

:7538b522 KERNELBASE.RaiseException + 0x62
:030f850a HookedRaiseException + $66
:50162931 rtl280.@System@Classes@TReader@ReadBuffer$qqrio + 0x55

 

After that the following exception is:

 

First chance exception at $7538B522. Exception class EArgumentOutOfRangeException with message 'Argument out of range'. Process XXXXX.exe (17800)

:7538b522 KERNELBASE.RaiseException + 0x62
:030f850a HookedRaiseException + $66
:50159093 rtl280.@System@Classes@TCollection@GetItem$qqri + 0x13
:50159093 rtl280.@System@Classes@TCollection@GetItem$qqri + 0x13
:50cc5327 vcl280.@Vcl@Controls@TControl@Resize$qqrv + 0x1b
:50ccac1a ; C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\vcl280.bpl
:50ccacec vcl280.@Vcl@Controls@TWinControl@AlignControl$qqrp21Vcl@Controls@TControl + 0x68
:50ccad47 vcl280.@Vcl@Controls@TWinControl@Realign$qqrv + 0x7
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50e021a3 vcl280.@Vcl@Forms@TCustomForm@ScaleForPPIRect$qqrip18System@Types@TRect + 0x9b
:fffffff8

 

I don't have a test case for this as I put it on delay and re-testing with D12. Since Embarcadero thinks that it is not relevant to give a valid roadmap I promised to management at the company I work for that this should be fixed in Delphi 12. It's bad that Embarcadero follows the pattern from the past and now entered into the period when they hide every possible information.

 

[Guest]

1 hour ago, dummzeuch said:

Every rescaling of a control seems to cause a redraw of the whole form.

This is my observation too. The VCL cascades calculations and in a lot of situations there are redundant calculations on a scale of magnitude.

[qubits 20]

Thanks Guys for comments.

And I have had to do quite a few rewrites, already had to ditch allot of text controls, some ghost crawled into my machine.

But hey, less is more sometimes.

about 2 more days and I'll know.

 

This is all in 3d, i only use rectangles and spheres.

One form3d, nothing on it.

apk size is at about 16mb with including 20 animated themes.

been fun, coordinates, boggle my brain still, just divide by 2 and throw a gap there, idk.

 

I do think I understand the issue.

I make things based off of the width, height which on android is very small 916x411, but in reality it's 2520x1080, when it up scales i would imagine it making best choices as there's not enough pixels to fill it.

And I also kind of remember that opengl liked everything to be on integers or uses a sub par rendering, which I already tried but I used 916x411 as my start, so my sizes and positions when scaled are definitely not integers, so I redo that as well just to see.

 

 

 

 

[Uwe Raabe 2057]

In Delphi 11 there is an option to speed up VCL styled applications which is probably not commonly known, because it wasn't communicated much: Vcl.Themes.TStyleManager.UseParentPaintBuffers

 

While the linked doc is pretty much useless, the common description gives some more insight: Styles Performance Improvements

[qubits 20]

happy to say, pixel perfection has been achieved.

yes, had to hand draw all text, some texture buffering.

and not totally implemented, so I know what I'm doing this weekend.

 

but pretty simple, make all bitmaps and draw all text multiplied by the current scale.

 

[dummzeuch 1505]

On 1/13/2022 at 4:03 PM, Uwe Raabe said:

In Delphi 11 there is an option to speed up VCL styled applications which is probably not commonly known, because it wasn't communicated much: Vcl.Themes.TStyleManager.UseParentPaintBuffers

Thanks for the hint, but I didn't see any performance improvement when enabling it. It's possible that enabling is not enough though, but I have no idea what else to try.

[Uwe Raabe 2057]

1 hour ago, dummzeuch said:

I didn't see any performance improvement when enabling it.

It only has an effect when VCL styles are used. For plain VCL applications it has no influence.

Quote

Note: This feature works only if a VCL Style is active and it uses a significant additional amount of memory for storing images.

 

[Rollo62 536]

On 1/13/2022 at 2:36 AM, qubits said:

...

be cool if i could put a TMatrix on my scene, ....

Tl;Dr;

Like that ?

 

Edited January 15, 2022 by Rollo62

[qubits 20]

25 minutes ago, Rollo62 said:

Tl;Dr;

Like that ?

 

yes, just like that and know i also noticed, need to drop some tdummy's and replace with TSolidLayer3d which has this magical property and can also contain my kids.

will definitely be playing with this, could save me allot of work, was just going to do all the math by hand, thank you!! 🙂

[qubits 20]

nah, read only and probably just insane thinking i can set a scaled matrix but looking some more, maybe the camera matrix or i see a scale property.

not really needed as my textures and text is quite perfect now, just seeing if there is in fact a juicy center in that OpenGL tootsie pop.

thanks again!