[Bug]: Title Bar Images Stretched/Cropped (Regression)

[sdreb3421]

The new canary build (60.22.1.17) has introduced stretching/cropping of the icons/images in the krypton form title bar. This could be related to #601.

Stable:

Canary:

[Smurf-IV]

@sdreb3421 I am unable to replicate this (At any of the scaling I have on my QHD monitor with Win 10 20H2) Can you state what

• size display you are using
• scale applied
• Version of windows

[sdreb3421]

I was unable to resolve the issue with any scale setting unfortunately. The advanced scaling settings are disabled, but changing them didn't fix it either. Neither did changing the resolution of my monitor (native 1920x1080). The images below show my OS info, the results of various scaling (100%, 125%, 150%), and the images I used.

To replicate the issue, create an empty krypton form, no palette settings, and add button specs to the form using the three images below. The issue is most obvious when using smaller images that have rounded edges. If you're unable to replicate this I will go run some tests on other computers I can find.

[PWagner1]

Hi @sdreb3421 is it possible to use images, which are 24 x 24?

[Smurf-IV]

I was unable to resolve the issue with any scale setting unfortunately..... The images below show my OS info, the results of various scaling (100%, 125%, 150%), and the images I used. Are you saying that this is a problem even when 100% on Native scaling ?

What is the size of the images (i.e. 16x16 or something else) ( cannot see from the images you have chosen as they are png's, and they will may be stored as bitmaps internally)

Note: at this size bmp is more efficient than png overhead.

[Smurf-IV]

FYI See the following PR demo of Form butts with round images: https://github.com/Krypton-Suite/Standard-Toolkit/pull/604

[sdreb3421]

Yeah it would be okay to use 24px. Does that fix the issue? I can test it tomorrow morning...

[sdreb3421]

@Smurf-IV looks like you were able to replicate it in that PR. Is the issue the image size?

[PWagner1]

Yeah it would be okay to use 24px. Does that fix the issue? I can test it tomorrow morning...

Yes it does, please see @Smurf-IV previous comment for a demo.

[PWagner1]

@Smurf-IV looks like you were able to replicate it in that PR. Is the issue the image size?

@sdreb3421 They are using 24 or 25px

[sdreb3421]

@Smurf-IV I'm confused, are you saying they had the issue when using 24px, or that is the fix?

[sdreb3421]

I'm assuming this image size requirement doesn't just apply to button specs, but also applies to the form control buttons and form icon?

[Smurf-IV]

I'm assuming this image size requirement doesn't just apply to button specs, but also applies to the form control buttons and form icon?

Form Control buttons are ButtonSpecs.

The Form Icon is independent and should be an "Icon with multiple sized images " not a single bitmap image

[sdreb3421]

I just upgraded to the latest stable (60.22.2.32) and tried using a 24px button spec image, and the problem still exists. The help button spec below is 24px. We have tested with 16, 20, 24 and 32px with the same issue. The issue is applying to form button specs and navigator button specs. Have you guys been able to replicate the issue?

[sdreb3421]

Looks like #623 is likely the same issue.

[Smurf-IV]

Using the images supplied:

Results (Restart app between scale changes):

I was only able to see "Compression" (not clipping) when the images are rescaled down to 16*16 as expected for 100%.

[Smurf-IV]

@sdreb3421 tried to replicate by using the sample app to cover your repro steps: (To replicate the issue, create an empty krypton form, no palette settings, and add button specs to the form using the three images below. )

1) What Windows theme are you using? 2) What Krypton theme are you using?

[Smurf-IV]

1 thing I have noticed ("Due to compression"), is that the images are compressed more vertically, that they are horizontally:

[Smurf-IV]

Fix for the compression artefacts:

[Smurf-IV]

The above fix has "Now" rebroken the scaling of the images up:

[Smurf-IV]

I think I have fixed both scenarios:

[sdreb3421]

I think I have fixed both scenarios:

The image you're showing at 125% looks like what I'm seeing. Will the next nightly have the fix for me to test?

[Smurf-IV]

The image you're showing at 125% looks like what I'm seeing. Will the next nightly have the fix for me to test?

That is the idea, just not sure when the nightlies are built in relation to timezones (And manual prompts) , so get one that has least "day" .38 labelled (i.e today, as of writing)

[Smurf-IV]

.38 has just been released :-) https://discord.com/channels/620577714889424916/940148840504373260

[sdreb3421]

Fixed in the latest nightly! Thanks

[sdreb3421]

@Smurf-IV @Wagnerp I'm not sure what happened, but I am seeing this same issue again after updating from 6.2201.4 to the latest version 65.22.6.152.

Can you confirm that the nightly fix was added to the code base? Thanks

[Smurf-IV]

@Wagnerp

Can you confirm that the nightly fix was added to the code base? Thanks

[PWagner1]

@Wagnerp

Can you confirm that the nightly fix was added to the code base? Thanks

@sdreb3421 & @Smurf-IV

It should be, check the latest canary to see if it exists in there

[sdreb3421]

@Wagnerp @Smurf-IV I found the version where it transitioned from working to broken in each toolkit type.

Nightly: Working in 65.22.5.91-alpha. Broken in 65.22.5.94-alpha. Canary: Working in 65.22.3.89-beta. Broken in 65.22.4.103-beta Stable: Working in 6.2201.4. Broken in 60.22.2.32.

Is this enough to help locate the issue? Thanks

[Smurf-IV]

@Wagnerp in your court now.

[PWagner1]

@sdreb3421 Please retry using today's nightly

@Smurf-IV Somehow, old code snuck back in :)

[sdreb3421]

Fixed in Nightly 70.22.7.185-alpha!

However, when updating to this from stable 6.2201.4 I'm getting designer exceptions and a runtime exception (VS2022 latest version). The runtime exception is occurring on ((System.ComponentModel.ISupportInitialize)(this.tabMain)).EndInit(); Is this expected?

[PWagner1]

Fixed in Nightly 70.22.7.185-alpha!

However, when updating to this from stable 6.2201.4 I'm getting designer exceptions and a runtime exception. The runtime exception is occurring on ((System.ComponentModel.ISupportInitialize)(this.tabMain)).EndInit();

Old code might have got back in between 2201.4 & 70.22.7.185.

((System.ComponentModel.ISupportInitialize)(this.tabMain)).EndInit(); Is this expected?

Might be something to do with .NET 4.8.1, @Smurf-IV any ideas?

[sdreb3421]

I'm using VS 2022 with only NET6 as target framework. I can't also target net48 due to incompatible assemblies. However, designer looks good and no runtime exceptions with 6.2201.4.

[sdreb3421]

@Wagnerp @Smurf-IV should this fix have been included in the July canary release? I just installed and still see the icon distortion... Thanks

[PWagner1]

@Wagnerp @Smurf-IV should this fix have been included in the July canary release? I just installed and still see the icon distortion... Thanks

@sdreb3421 Yes it should be if it's fixed in the latest nightly.

[sdreb3421]

@Wagnerp @Smurf-IV you guys... what is happening here. The issue was fixed in nightly 70.22.7.185-alpha, but broken again in 70.22.7.194-alpha. This is the second time the fix has been removed. I blame it on the aliens.

Interestingly, when the fix was implemented (185 and 188), I get a runtime exception for the KNavigator. This exception went away again in 194 once the fix was removed. Exception details below. It looks like some of the new code for the button spec bitmaps is causing an exception with the KNavigator button specs...

System.ArgumentException HResult=0x80070057 Message=Parameter is not valid. Source=System.Drawing.Common StackTrace: at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format) at System.Drawing.Bitmap..ctor(Int32 width, Int32 height) at Krypton.Toolkit.CommonHelper.ScaleImageForSizedDisplay(Image src, Single trgtWidth, Single trgtHeight) at Krypton.Toolkit.ButtonSpecView.GetImage(PaletteState state) at Krypton.Toolkit.RenderStandard.AllocateImageSpace(StandardContentMemento memento, IPaletteContent paletteContent, IContentValues contentValues, PaletteState state, Rectangle displayRect, RightToLeft rtl, Size[,]& allocation) at Krypton.Toolkit.RenderStandard.GetContentPreferredSize(ViewLayoutContext context, IPaletteContent palette, IContentValues values, VisualOrientation orientation, PaletteState state, Boolean composition, Boolean glowing) at Krypton.Toolkit.ViewDrawContent.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewLayoutDocker.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewComposite.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewDrawSplitCanvas.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewDrawButton.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewComposite.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewLayoutCenter.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewLayoutDocker.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewComposite.GetPreferredSize(ViewLayoutContext context) at Krypton.Navigator.ViewLayoutInsetOverlap.GetPreferredSize(ViewLayoutContext context) at Krypton.Toolkit.ViewLayoutDocker.Layout(ViewLayoutContext context) at Krypton.Toolkit.ViewComposite.Layout(ViewLayoutContext context) at Krypton.Toolkit.ViewDrawPanel.Layout(ViewLayoutContext context) at Krypton.Toolkit.ViewManager.Layout(ViewLayoutContext context) at Krypton.Toolkit.ViewManager.Layout(IRenderer renderer) at Krypton.Toolkit.VisualControlBase.OnLayout(LayoutEventArgs levent) at Krypton.Navigator.KryptonNavigator.OnLayout(LayoutEventArgs levent) at Krypton.Navigator.KryptonNavigator.OnInitialized(EventArgs e) at Krypton.Toolkit.VisualControl.EndInit() at MotionView.AppUI.InitializeComponent() in C:\Users\sethd\Documents\TFS\MotionView\MotionView\MotionView\App\AppMainUI\AppUI.Designer.cs:line 1341 ((System.ComponentModel.ISupportInitialize)(this.tabMain)).EndInit();

[PWagner1]

@sdreb3421 The only fixed version I can think of was in this version. If I compile said version, are you able to test?

cc. @Smurf-IV

[PWagner1]

Got it! The 'fix' is here. Going to reimplement tomorrow.

[sdreb3421]

Awesome. Tag me and I'll test the nightly when it's time. Thanks

[PWagner1]

Hi @sdreb3421

Please re-test using today's nightly build, 213

[sdreb3421]

Looks perfect. And no runtime exceptions. Well done, thank you