Author Topic: Resolution  (Read 12986 times)

sveakul

  • Posts: 55
Re: Resolution
« Reply #50 on: 4 Sep '18 - 02:30 »
Rah'Dick:  In the post at https://www.un4seen.com/forum/?topic=17350.msg127709#msg127709 Ian said he thinks he could host your scaler on the XMPlay support site, have you talked with him about doing that now that you have the code complete?

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #51 on: 4 Sep '18 - 04:57 »
No, not yet. Many years ago I used to bother Ian by email, but today I'm thinking about rewriting my code so it works on my own webserver, instead of stealing someone elses' time. The thing is, I need ImageMagick for the conversion, but I only realised that my server, as opposed to my dev PC, doesn't have the PHP "imagick" extension after writing a good chunk of code. Since I'm on shared hosting, I also can't add the extension unfortunately. My server DOES have ImageMagick installed as CLI, however - so I might find out which extension API calls correspond to which CLI arguments and use PHP's exec() function.

Ian @ un4seen

  • Administrator
  • Posts: 21329
Re: Resolution
« Reply #52 on: 4 Sep '18 - 15:45 »
Unfortunately, the XMPlay support server doesn't currently have ImageMagick installed on it. I'll look into that.

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #53 on: 6 Sep '18 - 04:07 »
I found a way to do all the conversions using ImageMagick's CLI, which is working on my server. Expect a live version soon. :-)

[Edit]
It's online! You can try it here:
http://rahdick.at/sonstiges/xmplay-skin-scaler
« Last Edit: 6 Sep '18 - 08:41 by Rah'Dick »

Ian @ un4seen

  • Administrator
  • Posts: 21329
Re: Resolution
« Reply #54 on: 6 Sep '18 - 18:06 »
I gave it a try, and it seems to be working very nicely! :)

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #55 on: 6 Sep '18 - 18:30 »
Great! If you (or anyone else, really) encounter something broken, I'll see if I can fix it.  :)

deus-ex

  • Posts: 269
Re: Resolution
« Reply #56 on: 6 Sep '18 - 20:14 »
Ooops, I managed to break your tool at the very first try. ;)

I used Ian's repackaged version of your X-RD2506 skin posted here, and this is what I got: https://imgur.com/a/t0qcEOR

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #57 on: 6 Sep '18 - 23:28 »
Oh, I think I know what happened, but I'll have to look into it. Thanks!
Do you mind telling me the options that you used?

[Edit] nevermind, fixed it. I forgot to test the whole conversion branch of the code that deals with skins without "color_seethru" in skinconfig.txt, turns out there were quite a few bugs, which never triggered because I only tested with skins that had "color_seethru" defined. However, it should work now. Thanks again for testing!
« Last Edit: 7 Sep '18 - 00:15 by Rah'Dick »

deus-ex

  • Posts: 269
Re: Resolution
« Reply #58 on: 6 Sep '18 - 23:32 »
Sure, Scale factor 1.1 (also tried 1.0) and default Point filter, as you can also review from the download log of your excellent scaler page. :)
« Last Edit: 6 Sep '18 - 23:37 by deus-ex »

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #59 on: 7 Sep '18 - 00:29 »
I see there have been some fruitless attempts at converting some skins that must've failed because of the earlier bugs - should I delete them?

deus-ex

  • Posts: 269
Re: Resolution
« Reply #60 on: 7 Sep '18 - 06:10 »
There's really no point in keeping those up for download, I guess. Probably failed conversions shouldn't be made available for public download at all but for your internal review only in order to be able to fix any bugs.

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #61 on: 7 Sep '18 - 22:59 »
There's really no point in keeping those up for download, I guess. Probably failed conversions shouldn't be made available for public download at all but for your internal review only in order to be able to fix any bugs.
Alright, I changed the script a bit. Uploaded files will now only be kept for 24 hours. I also added a "blur" control for filtering and added some more safety checks for uploaded filenames.

deus-ex

  • Posts: 269
Re: Resolution
« Reply #62 on: 7 Sep '18 - 23:41 »
Alright, the green color issue is fixed. However the generated skins still have those click-transparent areas that I reported earlier which renders these skins unusable for me. Like I already mentioned, Ian's repacked version of the X-RD2506 skin does not have these issues.

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #63 on: 7 Sep '18 - 23:51 »
Alright, the green color issue is fixed. However the generated skins still have those click-transparent areas that I reported earlier which renders these skins unusable for me. Like I already mentioned, Ian's repacked version of the X-RD2506 skin does not have these issues.
I have no idea what could possibly cause this, since it's not happening here either on Win7 x64, Win10 or Linux Mint 18.3 with WINE 1.6.2. I'll try again in some virtual machines, let's see if I can replicate that somehow.
Just to make sure, you have the latest stuff version, right?

[Edit]
I made a version for you to test in GIMP - all panel* images are back to BMP with a single transparency color. Could you try and see if it works correctly? (File is bigger than 1MB, uploaded it to my own server)
https://rahdick.at/sonstiges/nextcloud/index.php/s/Ft9epGrPERtRxCQ
« Last Edit: 8 Sep '18 - 01:08 by Rah'Dick »

deus-ex

  • Posts: 269
Re: Resolution
« Reply #64 on: 8 Sep '18 - 01:02 »
Just to make sure, you have the latest stuff version, right?
Yes, as of currently it is v3.8.3.10.

I made a version for you to test in GIMP - all panel* images are back to BMP with a single transparency color. Could you try and see if it works correctly?
This version works fine, I did not find any click-transparent areas.

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #65 on: 8 Sep '18 - 01:07 »
This version works fine, I did not find any click-transparent areas.
Can you try unpacking the skin, renaming panel_main.bmp and using the attached PNG instead?
It's the BMP from earlier, just replaced the green with alpha.

[Edit]
@ Ian, I noticed that "Restrict rendering" is no longer applied directly but kicks in only when resizing the info window.
Also, may I ask how transparency is considered when clicking any window? If alpha is greater than zero? Obviously, when clicking fully transparent areas, the click will go through to the object behind it. So is there a possibility that not-fully-transparent areas might cause issues when trying to drag the window?
« Last Edit: 8 Sep '18 - 01:13 by Rah'Dick »

deus-ex

  • Posts: 269
Re: Resolution
« Reply #66 on: 8 Sep '18 - 06:16 »
Replacing panel_main.bmp with the attached panel_main.png the click-transparent area issue reoccurs.

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #67 on: 8 Sep '18 - 07:24 »
Replacing panel_main.bmp with the attached panel_main.png the click-transparent area issue reoccurs.
This is extremely curious. I'm positive that there is absolutely nothing weird going on in that image. Unfortunately, I haven't found a way of automatically converting the alpha channel back to a solid color using ImageMagick yet, but even if I do, it'll take away the ability to scale skins that make use of PNGs with alpha channels.
I strongly suspect it might be something on your end, maybe some funky combination of Windows patch levels and graphics drivers that cause XMPlay to function in unexpected ways. I've now tested this on five different computers, Win7, Win10 and Linux and they all worked as expected.

Just a shot in the dark, but could you try those PNG skins with a freshly downloaded copy of XMPlay without any other plugins or skins installed? Or even on another computer?
« Last Edit: 8 Sep '18 - 07:33 by Rah'Dick »

deus-ex

  • Posts: 269
Re: Resolution
« Reply #68 on: 8 Sep '18 - 22:29 »
Just a shot in the dark, but could you try those PNG skins with a freshly downloaded copy of XMPlay without any other plugins or skins installed?
That was quite a good idea. Though I did not download a fresh copy, instead I just copied XMPlay.exe along with Xmp-ZIP.dll to a different drive/folder, which is as fresh and pure as it possibly can get.

First attempt, all skins work without issues. Great! So I tried to identify the plugin or ini-entry possibly causing my issues, by partially adding back plugins and ini-entries step by step, which usually is a fail-proof method. After a few attempts though, with the skin issue not reoccurring, I got bold and tried with an exact copy of my XMPlay install folder. All the skins would work in the copied folder, but not in my original XMPlay installation folder. Wait, what?

After thinking about this for a little while, and checking the Windows registry for any related entries, I went for the ultimate test. I made an copy of my XMPlay folder at the same location and naming it simply "XMPlay2". And again, all skins work without issues in the copied folder, but still not in the original XMPlay installation. What the hell?

Then I got an idea and compared the properties of both XMPlay.exe files. It turned out that my original XMPlay.exe installation had the Override high DPI scaling behaviour activated and set to System (Enhanced) (Screenshot: https://imgur.com/a/5VIyqWT).

I did this a couple years ago, because XMPlays info bubble text for the volume would not be drawn properly while XMPlays info text scaling is set to anything other than "normal", which I had to change since with default settings the bubble text is too small on my 4K monitor. It turns out that nowadays the High-DPI override isn't necessary anymore, XMplays info bubble text displays just fine on any scaling setting for me. With the Override high DPI scaling behaviour disabled (Windows default setting) the skin click-transparency issues disappeared.

I'm terribly sorry for the headaches and restless hours I must have caused you. Thank you for your patience and great support on this issue, its very much appreciated!

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #69 on: 8 Sep '18 - 23:20 »
Yayy! Congrats!  ;D Good to know that this Windows setting is causing the issues. Thanks for investigating!  :)

deus-ex

  • Posts: 269
Re: Resolution
« Reply #70 on: 9 Sep '18 - 07:12 »
Another thing I noticed converting the X-RD2506 skin with several scaling factors from 1.1 through 1.5. With a scaling factor of 1.3 or 1.4 the digits in the playtime display shift back and forth a little horizontally which appears to be related to the defined spacing of the digit "1". Scaling factors from 1.0 through 1.2 and 1.5 are not affected.

If I understand correctly these digits are not derived from a BMP contained within the skin, but from a font that XMPlay uses internally. That would also explain why different applied pixel filter blurring factors (1.0, 1.5, 2.0) do not affect the appearance of the digits. With a scaling factor of 1.5 the digits look quite blocky.

deus-ex

  • Posts: 269
Re: Resolution
« Reply #71 on: 9 Sep '18 - 07:55 »
In the meantime, here is an XMPlay update with a 2x size option for testing:

   www.un4seen.com/stuff/xmplay.exe

It adds a "Big" option to the "Appearance" options page. Please report any problems.
Works splendid so far. Can you extend the scale range from 1.0 to 2.0 using 0.1 incremental steps?


The issue with filtering is when a colour is used to indicate transparent areas (which most skins do), and that colour ends up blended into the edges. I may look into automatically adding an alpha channel in those cases, to prevent that problem.
Font smoothing is definitely required, but instead of an automatically applied filter please make it an option, probably along with a few different strength factors and/or methods.

And the very cherry on top would be definable keyboard shortcuts to in-/decrease the skin scaling factor on the fly.

Rah'Dick

  • XMPlay Support
  • Posts: 963
Re: Resolution
« Reply #72 on: 9 Sep '18 - 20:35 »
[...]
Font smoothing is definitely required, but instead of an automatically applied filter please make it an option, probably along with a few different strength factors and/or methods.
[...]
AFAIK, the fonts are just rendered through Windows APIs, so this is nothing XMPlay can influence, short of implementing its own font renderer. This is also the reason why I can't influence the font appearance while scaling - my tool just reads the original font size number, as defined in skinconfig.txt, multiplies it with the scaling factor and then rounds the result to the nearest integer, since fractional font sizes aren't supported in skinconfig.txt (I might be wrong, tho).

Some fonts (especially those from Microsoft) contain bitmaps for smaller font sizes, even though they are vector fonts (TTF, OTF). To make these fonts render their vectors even in smaller sizes, you'd have to edit the font file and remove the bitmaps (FontForge can do that). There's no way built into Windows to smoothly resize these font bitmaps, sorry.

deus-ex

  • Posts: 269
Re: Resolution
« Reply #73 on: 11 Oct '18 - 20:17 »
Hi Ian,

you probably missed that my previous post in this thread was addressed to you. Could you please check it and respond? Thank you.

Ian @ un4seen

  • Administrator
  • Posts: 21329
Re: Resolution
« Reply #74 on: 12 Oct '18 - 15:39 »
Sorry, I did indeed miss that.

In the meantime, here is an XMPlay update with a 2x size option for testing:

   www.un4seen.com/stuff/xmplay.exe

It adds a "Big" option to the "Appearance" options page. Please report any problems.
Works splendid so far. Can you extend the scale range from 1.0 to 2.0 using 0.1 incremental steps?


The issue with filtering is when a colour is used to indicate transparent areas (which most skins do), and that colour ends up blended into the edges. I may look into automatically adding an alpha channel in those cases, to prevent that problem.
Font smoothing is definitely required, but instead of an automatically applied filter please make it an option, probably along with a few different strength factors and/or methods.

And the very cherry on top would be definable keyboard shortcuts to in-/decrease the skin scaling factor on the fly.

When adding the 2x "big" option, I did also look into allowing pretty much any scale on the fly, eg. using the mouse wheel to adjust. It worked by rendering the window in normal size off screen and then resizing the whole thing before displaying. It worked OK in general but there were issues. The big issue was that text looked bad when blown up that way. Another issue was the extra CPU usage of the resizing, which is avoided by pre-scaling everything when loading the skin (as the "big" option does).

The issue with doing fractional size changes when pre-scaling is that the controls/buttons are drawn on pixel boundaries but the correct positions and sizes may no longer be on a pixel boundary, so they may not look quite right. Rendering in normal size and then resizing avoids that issue but has the other issues mentioned.