It is currently May 11th, 2024, 1:56 pm
[D2D] Line meter wrong positioning and pixel skipping
-
- Developer
- Posts: 22632
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Line meter wrong positioning and pixel skipping
New beta r3258 is out...
-
- Posts: 100
- Joined: April 30th, 2017, 11:51 am
Re: Line meter wrong positioning and pixel skipping
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
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.
It only is so when GraphStart=left. With "Right" everything is OK.rxtd wrote:2. In 4.3 Line is delayed for one update.
I tried to play with it in last 4.2 build, and seems like 4.2 and 4.3 behaves almost the same way.rxtd wrote:1. When used with TransformationMatrix behavior in 4.2 and 4.3 differs
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.
-
- Developer
- Posts: 2694
- Joined: November 24th, 2011, 1:42 am
- Location: Utah
Re: Line meter wrong positioning and pixel skipping
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:
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
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
-
- Developer
- Posts: 22632
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Line meter wrong positioning and pixel skipping
New beta r3260 is available.
-
- Posts: 100
- Joined: April 30th, 2017, 11:51 am
Re: Line meter wrong positioning and pixel skipping
Yeah, I didn't realize that !Update bang causes a redraw. I think it should be noted in the documentation .
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
UPD. Well, now I believe it is a rendering problem. Last value of a Line is always the same as second-to-last value. (I delayed histogram values)
You do not have the required permissions to view the files attached to this post.
-
- Posts: 100
- Joined: April 30th, 2017, 11:51 am
Re: Line meter wrong positioning and pixel skipping
One more Line-related problem.
Minimum and maximum values are blurred, and maximum values go beyond meter bounds when antialiasing is enabled. 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:
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).
Minimum and maximum values are blurred, and maximum values go beyond meter bounds when antialiasing is enabled. 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:
You do not have the required permissions to view the files attached to this post.
-
- Posts: 919
- Joined: January 30th, 2017, 2:01 am
- Location: Greece
Re: Line meter wrong positioning and pixel skipping
If you click the word "Update" you can see the definition for it. There you can see that update includes a redraw.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 .
-
- Posts: 100
- Joined: April 30th, 2017, 11:51 am
Re: Line meter wrong positioning and pixel skipping
Any progress on this?
EDIT: OK, waiting for RC2.