MP2 - Spring'16 [MP-638] Cropped images by SkinEngine (1 Viewer)

[morpheus_xx]

@Brownard could this be the cause for our problem? The following articles are about the different positions of "texel" (texture) and "pixel" (screen):

http://drilian.com/2008/11/25/understanding-half-pixel-and-half-texel-offsets/
https://msdn.microsoft.com/en-us/library/bb219690(VS.85).aspx

My fix attempt went into same direction (manipulating texture position/size), but maybe we need to check the vertex definitions? Here we are currently shifting position by -0.5 top/left but making the rect also +1 pixel wide. This would be the "outer boundary" of screen pixels. But if I understand the posts above correctly, this might not be correct?

 

[Brownard]

@Brownard could this be the cause for our problem? The following articles are about the different positions of "texel" (texture) and "pixel" (screen):

http://drilian.com/2008/11/25/understanding-half-pixel-and-half-texel-offsets/
https://msdn.microsoft.com/en-us/library/bb219690(VS.85).aspx

My fix attempt went into same direction (manipulating texture position/size), but maybe we need to check the vertex definitions? Here we are currently shifting position by -0.5 top/left but making the rect also +1 pixel wide. This would be the "outer boundary" of screen pixels. But if I understand the posts above correctly, this might not be correct?

It does sound possible given that the images are being cropped at the bottom/right. I've had a play around but as far as I can tell the problem just gets shifted to different sides of the image

 

[morpheus_xx]

I also experimented with the vertex offsets. I pushed my changes to branch EXP_FixTexturePositions. I commented all manual offsets (-0.5) and moved the modification to PrimitiveBuffer, which then modifies all vertices with this offset.

If you check the changes, some places in code did a "-0.5" in all values, few places did a "-0.5" in one edge, but then "+0.5" on the other edge (thus making the rect in sum 1 pixel larger). But according to MS article this is not correct, as the rasterizer than renders one more pixel.

There are visible differences (corona around buttons, shape of highlighted audio tab button), but in my example screenshots the original one looks better?



(without suffix are the ones after my change, the _orig files are the ones from master)

 

[morpheus_xx]

After checking my own screenshots I found that this change has an impact on the font rendering issue as well: https://forum.team-mediaportal.com/...intel-hd-chipsets-on-windows-10.134458/page-2.

I think it fixes the "ghost dots" above letters, maybe not 100%, but it's a lot better!

@Lehmden

 

[ge2301]

Did you remove the adjustment margins for the menu tile focus frames before testing?
https://github.com/MediaPortal/Medi...es/Titanium Extended/styles/Buttons.xaml#L253

I added them to minimize the crop effect.

 

[morpheus_xx]

Did you remove the adjustment margins for the menu tile focus frames before testing?

I've seen the margins after testing a bit further. I tried to adjust them as well, but result is not correctly yet.

As there are also some problems with scrolling texts, I think there might be still an issue with opacity masks (i.e. round corners in home tiles) and/or "render to texture" methods (required for Opacity masks, VisualBrush...).

So it needs more checks, but at least I think we are on the right way

 

[HTPCSourcer]

I think, we are larmenting from something of a great height.

I tried to spot the effects and really had issues to see them. The average user will probably not even take notice of it. This doesn't mean that we should not try to get it to 100%, but it is already a very good state of work.

 

[ge2301]

Just that this topic is not forgotten. We should really nail the root cause after release of MP2.1 and find a solution.
As you know I implemented some rotating indicators (in future there might be also CD's etc.) and I wondered why those rotate like an egg. It looks horrorable.
The reason is simply, that the cropped parts of the image are also affecting the center point of the image. So setting an animation around (0.5,0.5) means the images rotate on an elliptic path.
According the the image size I have to set for every image another center point (e.g. 0.49,0.48) to make the image almost rotate smoothly around the center.
This is really a nogo for a modern skin engine.