Ah, that makes sense. It sometimes happens that the culprit is not strictly in the main "line" of the process, but in a part of it that isn't usually investigated because it's assumed to do things right. Fixing it is great news, thanks!Brian wrote: ↑September 1st, 2022, 2:46 pmTransformationMatrix is applied before any drawing occurs. It's the first step.
When the shadow is applied, it needs to create another "target" to draw on since we are only applying a shadow to a portion of the text. This "target" uses the same dimensions as the skin....but in this case, those dimensions are truncated by SkinWidth. Then the shadow is drawn just before the regular text.
So, while the TM is applied before the shadow is rendered, the rendering assumed the dimensions incorrectly.
Good news, I fixed it. Instead of using the skins dimensions, I used the meter's dimensions.
Honestly, this would have never come up with using TM.
Nah, the testing was ok - in the case of TM, too much testing would have probably resulted in not including such a useful option in Rainmeter in the first place because it's harder to understand. I generally prefer things as they come, irrespective of complexity, because that allows for much greater flexibility compared to versions that, for the sake of simplicity, would diluate the capabilities to a couple of developer selected features for the simple minded users and therefore preventing full customization of the process (Microsoft is a champion at that, lately) - same for the ColorMatrix option. I'm just saying that, if setting the "center" point of the transformation and the mouse detection issue had a solution at that time, presenting the option in a more friendly manner to the user would have been nice to have, that's all.Brian wrote: ↑September 1st, 2022, 2:46 pmYes, there are easier ways to do this...however, when migrated from GDI to D2D, the goal was to get the same visual representation between the 2 rendering systems. Due to the high amount of effort this was, we often used the closest API functions to GDI as we could. This meant less "manual" testing at the time.
And yes, meter transforms are on the "TODO" list.....the never ending list.
That being said, improvements can always be done, at any time - hopefully without affecting flexibility and customization. I would love to be of help in minimizing the developers' TODO list as long as my free time still permits it, but as mentioned on other occasions, C++ is still not quite my language of choice due to its specific and less "natural" syntax. I can, however, come up with plenty of ideas on how to solve things, I'm never ever short of that, LOL.
So, just out of curiosity, am I right that currently the only obstacle in adding a friendlier TM would be identifying the transformed meter's boundaries so that mouse is correctly detected only on the meter area (since setting the transformation "center" seems possible by looking at the way it is handled by the Shape meter's transform modifiers, assuming they do things similar to how they are done in the C++ examples mentioned earlier)?
