It is currently December 10th, 2018, 6:36 pm

Line meter wrong positioning and pixel skipping

Testing and discussion of the conversion of Rainmeter to D2D.
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 14th, 2018, 4:26 pm

New beta r3258 is out...
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Re: Line meter wrong positioning and pixel skipping

rxtd » October 14th, 2018, 5:07 pm

Yay, r3258 solves one tiny problem, that I didn't deem important enough to be reported: that max values of an antialiased Line is blurred while 0 is not :)

rxtd wrote:2. In 4.3 Line is delayed for one update.
It only is so when GraphStart=left. With "Right" everything is OK.
rxtd wrote:1. When used with TransformationMatrix behavior in 4.2 and 4.3 differs
I tried to play with it in last 4.2 build, and seems like 4.2 and 4.3 behaves almost the same way.
I 100% sure that about 1.5 years ago I saw what I described in that post but it probably was some bug that has been fixed long time ago.
Seems like 4.2 only sets LineWidth automatically. Or, to be correct, multiplies LineWidth automatically.
Sorry. I edited my initial post.
But I still think that 4.3 then should multiply LineWidth too.
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 16th, 2018, 5:05 am

The TransformationMatrix issue with Line meters has been brought up before. See here: https://forum.rainmeter.net/viewtopic.php?f=123&t=29055#p151555

For some reason (must be the inner workings of GDI+), the Line meter used in that skin was not responding to TransformationMatrix. Doing some basic tests at the time, I could not produce a Line meter using TransformationMatrix that would draw the line with only the defined LineWidth. So, determining it was a bug, I thought I had corrected the bug by forcing the line to draw at the LineWidth defined, and not be transformed by TransformationMatrix.

But using your test skin, I realized my mistake and have reverted my previous changes.


However, this doesn't solve the problem in the other skin (linked above). So we decided to add a new option that can force the line to use the LineWidth and ignore any transformations from TransformationMatrix.

The new option for Line meters is called TransformStroke. It's options are:
  • Normal (default): This means the stroke (or line in this case) will respect any transforms from TransformationMatrix and the LineWidth.
  • Fixed: This means the stroke will not respect any transforms from TransformationMatrix, but will respect the LineWidth option. This means you can stretch and skew the meter with TransformationMatrix, but the line's width will remain with what is defined by LineWidth.


The delayed issue is tricky as well. This seems to be caused in a different section of code (not by the Line meter itself). It's most likely a bug in rendering.

With your code, the delay seems obvious...but you may not realize in your code, there is 2 (or maybe even 3 depending on the timing) redraws happening on your LeftMouseUpAction. The !Update bang causes a redraw, then !Redraw is another (obviously), and if the timing is just right, the regular update cycle is the third one.

If you modify the code a little, the issue doesn't happen often:
LeftMouseUpAction=[!setoption ram formula 1][!updatemeasure ram][!updatemeter *][!redraw]

I think once we tweak the drawing time a little, your previous code will also work.

-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 16th, 2018, 1:24 pm

New beta r3260 is available.
rxtd
Posts: 65
Joined: April 30th, 2017, 11:51 am

Re: Line meter wrong positioning and pixel skipping

rxtd » October 17th, 2018, 10:49 am

Brian wrote:
October 16th, 2018, 5:05 am
you may not realize in your code, there is 2 (or maybe even 3 depending on the timing) redraws happening on your LeftMouseUpAction. The !Update bang causes a redraw
Yeah, I didn't realize that !Update bang causes a redraw. I think it should be noted in the documentation .
Brian wrote:
October 16th, 2018, 5:05 am
If you modify the code a little, the issue doesn't happen often:
LeftMouseUpAction=[!setoption ram formula 1][!updatemeasure ram][!updatemeter *][!redraw]
Interesting. With [!updatemeter *] the delay still exists but is relatively small, and I notice it mostly because I can compare it with 4.2. With [!updatemeter line] delay is ~1 update. And if I use [!updatemeter line][!updatemeter line] then the line changes immediately — but does it have anything to do with rendering?
Unfortunately, I can't use this half-solution in my skins because I don't use bangs in it, I just used it here to show the problem. I use Line with Histogram to make a shadow-like effect, and it's very noticeable that line is not synchronized with histogram :confused:

UPD. Well, now I believe it is a rendering problem. Last value of a Line is always the same as second-to-last value.
2018-10-17_18-53-19.png
(I delayed histogram values)
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 » November 2nd, 2018, 10:40 pm

One more Line-related problem.
Minimum and maximum values are blurred, and maximum values go beyond meter bounds when antialiasing is enabled.
2018-11-03_06-01-37.png
As you can see in the picture, all values have something like -0.1 Y-offset. In the bottom zero values make background white, and in the top that and line is drawn in the first pixel row where it should not be drawn because its bounds start at second pixel row.
If you use Color picker then you see that line pixels in the bottom are not 0xffffff, and difference in color of background pixels can be seen without any instruments.
Tested on r3260.
My test skin:

Code: Select all

[mt]
measure=calc
formula=1

[back]
meter=image
h=100
w=100
solidcolor=112233

[line]
meter=line
MeasureName=mt
x=1
y=1
h=98
w=98
linecolor=ffffff
antialias=1
I know that in 4.2 line had 0.5 pixel offset, but I personally think that it was a bug, and at least 0.5 offset was understandable (pixel grid instead of pixel rectangles).
You do not have the required permissions to view the files attached to this post.
User avatar
kyriakos876
Posts: 849
Joined: January 30th, 2017, 2:01 am
Location: Greece

Re: Line meter wrong positioning and pixel skipping

kyriakos876 » November 3rd, 2018, 10:00 am

rxtd wrote:
October 17th, 2018, 10:49 am
Yeah, I didn't realize that !Update bang causes a redraw. I think it should be noted in the documentation .
If you click the word "Update" you can see the definition for it. There you can see that update includes a redraw.