It is currently December 10th, 2018, 8:51 pm

Line meter wrong positioning and pixel skipping

Testing and discussion of the conversion of Rainmeter to D2D.
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Line meter wrong positioning and pixel skipping

rxtd » October 11th, 2018, 11:50 am

Issues:
Disclaimer: Images below have different Flip option values set, but I didn't notice any difference between flip=1 and flip=0, I just didn't want to make another dozen of screenshots.
All pictures are enlarged 8 times using nearest neighbour algorithm. Light gray is skin background, dark gray is line background.

With hardware acceleration:
When GraphStart=Right line is one pixel shorter than it should be.
2018-10-11_18-03-38.png
When GraphStart=Left line is moved to one pixel left and one pixel up.
2018-10-11_18-04-33.png
Without hardware acceleration:
When GraphStart=Left line is moved to one pixel up.
2018-10-11_18-19-40 gdi.png
With antialiasing:
Same as without antialiasing but line is always moved half pixel left. You can see it in the last picture.

Also, sometimes pixels are just skipped. For me it happens randomly (probably depends on line data) in both GDI and D2D modes.
2018-10-11_18-20-14 gdi.png
Here is example of how it looks on my more complex skin: image is scaled 600% using nearest neighbour algorithm.
2018-10-11_17-58-28 cut.png
My test skin:

Code: Select all

[back]
meter=image
h=30
w=100
solidcolor=888888

[ram]
measure=PhysicalMemory

[line]
meter=line
measurename=ram
x=1
y=1
h=28
w=98
flip=1
GraphStart=left
solidcolor=112233aa
linecolor=ff00bbaa
antialias=0
Version info:

Code: Select all

Rainmeter 4.3.0.3255 beta (64-bit)
Language: English (1033)
Build time: 2018-10-09  6:26:39
Commit Hash: d7c6ad6e
Windows 10 Enterprise 2016 LTSB 1607 64-bit (build 14393) - English (1033)
Brian wrote:Hopefully no more issues with the Line meter. :D
Sorry!
You do not have the required permissions to view the files attached to this post.
User avatar
Brian
Developer
Posts: 1793
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Line meter wrong positioning and pixel skipping

Brian » October 13th, 2018, 6:04 am

Damn! jsmorley is going to fire me!

Issues should be fixed for the next beta! Thanks for reporting!

rxtd wrote:... in both GDI and D2D modes.
Also, just to clarify. There is no "GDI vs D2D mode". Rainmeter 4.2 used GDI+ to render a lot of meters (but not all). Rainmeter 4.3 strictly uses D2D only - which can be hardware accelerated or not (which is probably what you meant by GDI+ vs D2D mode).

-Brian
User avatar
jsmorley
Developer
Posts: 18445
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Line meter wrong positioning and pixel skipping

jsmorley » October 13th, 2018, 1:10 pm

Beta r3256 released...

There goes the corner office Brian. ;-)
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Re: Line meter wrong positioning and pixel skipping

rxtd » October 13th, 2018, 1:55 pm

Positioning looks fully correct in the r3256.
Pixel skipping is also gone.

However, I found two more issues.
First could be nitpicking, but with antialiasing the first (most current) pixel is not fully drawn. It's like you draw a line not to a pixel center but with ~0.5 pixel offset. I would not count it as a problem but leftmost and rightmost pixels behave differently.
2018-10-13_20-31-28+.png
Second is 100% bug. It's probably linked to some rounding issues.
Without antialiasing the most current pixel sometimes disappears. For me it randomly happens for one update, the majority of time everything is fine.
2018-10-13_20-36-09.png
Actually, I think that both problems may have the same root.
Hardware acceleration does not affect these issues.
Test skin code (same as in my previous post):

Code: Select all

[back]
meter=image
h=30
w=100
solidcolor=888888

[ram]
measure=PhysicalMemory

[line]
meter=line
measurename=ram
x=1
y=1
h=28
w=98
flip=0
GraphStart=left
solidcolor=112233aa
linecolor=ff00bbaa
antialias=0

[back2]
meter=image
h=30
w=100
solidcolor=88888800
LeftMouseUpAction=[!refresh]
You do not have the required permissions to view the files attached to this post.
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Re: Line meter wrong positioning and pixel skipping

rxtd » October 13th, 2018, 3:43 pm

I think you won't mind if I will post one another Line meter-related issue without creation of a new thread.
I'm not really sure if it is a bug or undocumented behavior.
If you feed Line meter with negative values then it is goes beyond it's bounds.
2018-10-13_22-44-21.png
I hope you like new bugs just as much as I do :D

Test skin code:

Code: Select all

[back]
meter=image
h=30
w=100
solidcolor=888888

[ram]
measure=calc
formula=-1

[line]
meter=line
measurename=ram
x=1
y=1
h=28
w=98
flip=0
GraphStart=left
solidcolor=112233aa
linecolor=ff00bbaa
antialias=1
You do not have the required permissions to view the files attached to this post.
User avatar
Brian
Developer
Posts: 1793
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Line meter wrong positioning and pixel skipping

Brian » October 14th, 2018, 5:04 am

Thanks for reporting all these bugs. There are so many options with all the meters, it's hard to test them all.

I think I have fixed these issues as well, available with the next beta.

rxtd wrote:First could be nitpicking, but with antialiasing the first (most current) pixel is not fully drawn. It's like you draw a line not to a pixel center but with ~0.5 pixel offset. I would not count it as a problem but leftmost and rightmost pixels behave differently.
Yeah, unfortunately anti-aliasing will never be the same with D2D vs GDI+ since the position of their underlying "unit" is different. GDI+ works in whole pixels, while D2D works in DIPs (device independent pixels), with the "starting point" of the unit half way between each pixel. Since we have to mimic GDI+ for backwards compatibility, an offset was added to the line meter in various places which is the reason why things were "slightly" off. We don't adjust anything when drawing with anti-aliasing, we just ask the rendering engine (D2D) to do it for us. So basically, it will be close, but not pixel perfect.

rxtd wrote:Second is 100% bug. It's probably linked to some rounding issues.
Without antialiasing the most current pixel sometimes disappears. For me it randomly happens for one update, the majority of time everything is fine.
These rounding issues actually existed in Rainmeter 4.2 and prior, but they have definitely popped up more often with all the tweaking to 4.3 (mostly due to the issues describe above). I adjusted the offset a bit, so hopefully these rounding issues will be to a minimum.

rxtd wrote:I'm not really sure if it is a bug or undocumented behavior.
If you feed Line meter with negative values then it is goes beyond it's bounds.
Good catch, definitely a bug since Rainmeter 4.2 does not do this. Apparently, the issue was with some bounds checking that was not taking the offset into account.


Here is the test skin I used (modified and expanded version of your test skin)

Code: Select all

[Variables]
Width=129
Height=30
AA=0

[BackStyle1]
X=-1r
Y=4R
W=#Width#
H=#Height#
SolidColor=888888

[BackStyle2]
X=4R
Y=-1r
W=#Height#
H=#Width#

[LineStyle1]
MeasureName=Ram
X=1r
Y=1r
W=(#Width# - 2)
H=(#Height# - 2)
SolidColor=112233AA
LineColor=FF00BBAA
AntiAlias=#AA#

[LineStyle2]
W=(#Height# - 2)
H=(#Width# - 2)
GraphOrientation=Horizontal

[Ram]
Measure=PhysicalMemory
;Measure=Calc
;Formula=-1


; Vertical GraphOrientation
[Back1]
Meter=Image
MeterStyle=BackStyle1
X=0
Y=0

[Line1]
Meter=Line
MeterStyle=LineStyle1
GraphStart=Left
Flip=1

[Back2]
Meter=Image
MeterStyle=BackStyle1

[Line2]
Meter=Line
MeterStyle=LineStyle1
GraphStart=Left
Flip=0

[Back3]
Meter=Image
MeterStyle=BackStyle1

[Line3]
Meter=Line
MeterStyle=LineStyle1
GraphStart=Right
Flip=1

[Back4]
Meter=Image
MeterStyle=BackStyle1

[Line4]
Meter=Line
MeterStyle=LineStyle1
GraphStart=Right
Flip=0

;Horizontal GraphOrientation
[Back5]
Meter=Image
MeterStyle=BackStyle1 | BackStyle2
X=0
Y=4R

[Line5]
Meter=Line
MeterStyle=LineStyle1 | LineStyle2
GraphStart=Left
Flip=1

[Back6]
Meter=Image
MeterStyle=BackStyle1 | BackStyle2

[Line6]
Meter=Line
MeterStyle=LineStyle1 | LineStyle2
GraphStart=Left
Flip=0

[Back7]
Meter=Image
MeterStyle=BackStyle1 | BackStyle2

[Line7]
Meter=Line
MeterStyle=LineStyle1 | LineStyle2
GraphStart=Right
Flip=1

[Back8]
Meter=Image
MeterStyle=BackStyle1 | BackStyle2

[Line8]
Meter=Line
MeterStyle=LineStyle1 | LineStyle2
GraphStart=Right
Flip=0

Here is my results (4.2 on the left, 4.3 on the right).

Test #1: No hardware acceleration, no anti-alias
Line1_Big.png
Test #2: No hardware acceleration, anti-alias
Line2_Big.png
Test #3: Hardware accerlated, no anti-alias
Line3_Big.png
Test #4: Hardware accelerated, anti-alias
Line4_Big.png
To me, the only noticeable differences are in the anti-aliasing algorithm. There will be a few pixels here and there that are different from Rainmeter 4.2, especially in the peaks and valleys of the graph - but hopefully this will get us close enough.

-Brian
You do not have the required permissions to view the files attached to this post.
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Re: Line meter wrong positioning and pixel skipping

rxtd » October 14th, 2018, 10:34 am

Two more bugs related to Line meter. I probably should have renamed this thread.

1. When used with TransformationMatrix behavior in 4.2 and 4.3 differs:
In 4.2 line itself is affected by transformations. If I scale meter, then line is scaled. If I scale meter only in one dimension, line is also scaled in this dimension (which looks horrible). I didn't test it but it's obvious that other transformations also affect line. Sorry, after some testing I found out that I was wrong about stroked text.
In 4.3 only point positions are affected. If I scale line then meter have bigger size, but line itself is still thin.
I actually like this new behavior and don't want it to be changed because transformations in old style often looks bad, and there is no way to have line with consistent width and height if scale for X and Y are not equal. New behavior is really sweet, it is what I would expect from line transformations. But it is still a compatibility issue.
Can you add an option to use this new transformation matrix handling if (or when) you fix it?
2018-10-14_17-19-12.png
2. In 4.3 Line is delayed for one update.
I made a simple skin to test it: calc measure have value 0 and it is changed to 1 on mouse click. In 4.2 Line immediately goes to it's top, and in 4.3 it only happens one update later.
2018-10-14_17-22-13.png
Test skin code:

Code: Select all

[variables]
_scale=4

[back]
meter=image
h=(30*#_scale#)
w=(100*#_scale#)
solidcolor=888888
LeftMouseDownAction=[!setoption ram formula 1][!update][!redraw]

[ram]
measure=calc
formula=0

[line]
meter=line
measurename=ram
x=1
y=1
h=28
w=98
flip=0
GraphStart=left
solidcolor=112233aa
linecolor=ff00bbaa
antialias=1
TransformationMatrix=#_scale#;0;0;#_scale#;0;0
LineWidth=1

[str]
meter=string
measurename=ram
fontsize=30
You do not have the required permissions to view the files attached to this post.
Last edited by rxtd on October 14th, 2018, 5:13 pm, edited 4 times in total.
User avatar
balala
Rainmeter Sage
Posts: 7152
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Line meter wrong positioning and pixel skipping

balala » October 14th, 2018, 12:25 pm

rxtd wrote:
October 14th, 2018, 10:34 am
1. When used with TransformationMatrix behavior in 4.2 and 4.3 differs:
In 4.2 line itself is affected by transformations. If I scale meter, then line is scaled. If I scale meter only in one dimension, line is also scaled in this dimension (which looks horrible). I didn't test it but it's obvious that other transformations also affect line.
In 4.3 only point positions are affected. If I scale line then meter have bigger size, but line itself is still thin.
I actually like this new behavior and don't want it to be changed because transformations in old style often looks bad, and there is no way to have line with consistent width and height if scale for X and Y are not equal. New behavior is really sweet, it is what I would expect from line transformations. But it is still a compatibility issue.
As yourself said, this isn't necessary a disadvantage. I never tried to apply a TransformationMatrix to a Line meter before, but if I'd try it, this is exactly what I'd expect.
Plus if you want to increase the width, you can apply a LineWidth option. For example replace the LineWidth=1 with LineWidth=#_scale# ([line] meter).
So, I think this is a good and desirable improvement.
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Re: Line meter wrong positioning and pixel skipping

rxtd » October 14th, 2018, 12:32 pm

balala wrote:
October 14th, 2018, 12:25 pm
As yourself said, this isn't necessary a disadvantage. I never tried to apply a TransformationMatrix to a Line meter before, but if I'd try it, this is exactly what I'd expect.
Plus if you want to increase the width, you can apply a LineWidth option. For example replace the LineWidth=1 with LineWidth=#_scale# ([line] meter).
So, I think this is a good and desirable improvement.
Well, I like it too. And I know that there is LineWidth option.
But it has one major disadvantage: 4.3 is not compatible with skins that was created for 4.2 and earlier. No one will adjust "LineWidth" in thousands of old skins.
It's like AccurateText option in Rainmeter section: there is no reason not to use it but it can't be set as default because of backward compatibility.
User avatar
balala
Rainmeter Sage
Posts: 7152
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Line meter wrong positioning and pixel skipping

balala » October 14th, 2018, 12:45 pm

rxtd wrote:
October 14th, 2018, 12:32 pm
But it has one major disadvantage: 4.3 is not compatible with skins that was created for 4.2 and earlier. No one will adjust "LineWidth" in thousands of old skins.
I'm not sure this difference would cause any incompatibility. Yes, the Line meters which have applied scaling through TransformationMatrix don't look exactly the same, but in my opinion (at least) this isn't an incompatibility issue.