[BUGs] Image width limit using HA & Rainmeter in slow motion

[Yincognito]

Test skin:

Code: Select all

[Variables]
ModeUpdateDivider=1
Frames=360
Cols=360
Rows=1
Size=294

[Rainmeter]
Update=25
DynamicWindowSize=1
AccurateText=1

---Measures---

[Frame]
Group=SlideGroup
Measure=Calc
Formula=(Trunc((#Frames#+Frame+1)%#Frames#))
MaxValue=#Frames#
UpdateDivider=#ModeUpdateDivider#
DynamicVariables=1

[Set]
Group=SlideGroup
Measure=Calc
Formula=(Trunc(Frame/(#Rows#*#Cols#)))
UpdateDivider=#ModeUpdateDivider#
DynamicVariables=1

[Row]
Group=SlideGroup
Measure=Calc
Formula=(Trunc((Frame%(#Rows#*#Cols#))/#Cols#))
UpdateDivider=#ModeUpdateDivider#
DynamicVariables=1

[Col]
Group=SlideGroup
Measure=Calc
Formula=(Trunc((Frame%(#Rows#*#Cols#))%#Cols#))
UpdateDivider=#ModeUpdateDivider#
DynamicVariables=1

---Meters---

[Container]
Meter=Image
W=(#Size#)
H=(#Size#)
SolidColor=0,0,0,255
DynamicVariables=1

[Image]
Container=Container
Meter=Image
ImageName=#@#Test.png
ImageCrop=(#Size#*[Col]),(#Size#*[Row]),(#Size#),(#Size#),1
LeftMouseUpAction=[!SetVariable ModeUpdateDivider (-[#ModeUpdateDivider])][!PauseMeasureGroup SlideGroup][!UpdateMeasureGroup SlideGroup][!UnPauseMeasureGroup SlideGroup][!UpdateMeter *][!Redraw]
MouseScrollUpAction=[!SetOption Frame Formula (Trunc((#Frames#+[Frame]+1)%#Frames#))][!UpdateMeasureGroup SlideGroup][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetOption Frame Formula (Trunc((#Frames#+[Frame]-1)%#Frames#))][!UpdateMeasureGroup SlideGroup][!UpdateMeter *][!Redraw]
UpdateDivider=#ModeUpdateDivider#
DynamicVariables=1

[Text]
Meter=String
Y=0r
SolidColor=0,0,0,128
FontFace=Consolas
FontColor=255,255,255,255
FontSize=16
AntiAlias=1
Text="Frame = [Frame]#CRLF#Set   = [Set]#CRLF#Row   = [Row]#CRLF#Col   = [Col]#CRLF#Size  = #Size##CRLF#"
DynamicVariables=1

...\@Resources folder:

Test.png

Test.tif

Test256.png

Test256.tif

Results:
- with these values that are suited for a 294x294 "frame" out of 360 in a 105840x294 image, the "frame image" will partially then completely dissapear at Frame or Col 54 and 55, basically when reaching around 16384 or 2^16 pixels in width, if using Hardware Acceleration in Rainmeter (1st bug)
- when changing Frames, Cols and Size to 256 and ImageName to #@#Test256.png in order to load a 65536x256 image that contains 256 "frames" instead, Rainmeter will "almost" hang and go into slow motion, despite using the same settings / programs to write the TIF (Photoshop CS6) and the PNG (XnViewMP), and not changing anything in the code except lowering the values (2nd bug, discovered while preparing to post here the 1st bug)

Notes:
- yes, my drivers are the newest and all that, and I doubt this is the issue, since I had this problem on my older laptop as well, on a dedicated AMD GPU
- everything works fine without HA for the 1st bug, so I'm guessing it's an "internal" resolution limit at play here, that hopefully Rainmeter can "fix" if it's not to ingrained into Windows; by the way, this doesn't happen for images with the same content, if the frames are distributed more evenly into rows and columns (say, a 18 row x 20 columns layout)
- the 1st bug (didn't test the 2nd) applies to Bitmap meters as well, and this is the reason I posted the bug, since cropping on a different "row" is not an issue for Image meters
- this has not happened to me before, but some image viewers could not open the TIFs above, so this might be related to the 2nd bug
- the nVidia Control Panel and Start / Settings have no special configuration for Rainmeter, it's all on "let Windows decide" aka the integrated AMD Vega card, but it happens the same if I chose the dedicated nVidia Gefore GTX 1650
- be prepared to react appropriately for the 2nd bug (if you're able to reproduce it, that is), because the skin won't be visible then

In case it's still needed:

Code: Select all

NOTE (19:21:37.053) : Rainmeter 4.5.4.3550 (64-bit)
NOTE (19:21:37.053) : Language: English (1033)
NOTE (19:21:37.053) : Build time: 2021-10-04  9:25:19
NOTE (19:21:37.054) : Windows 10 Enterprise 2009 64-bit (build 19043) - English (1033)
NOTE (19:21:37.054) : Path: C:\Program Files\Rainmeter\
NOTE (19:21:37.054) : SkinPath: C:\Users\[User]\Documents\Rainmeter\Skins\
NOTE (19:21:37.054) : SettingsPath: C:\Users\[User]\AppData\Roaming\Rainmeter\
NOTE (19:21:37.054) : IniFile: C:\Users\[User]\AppData\Roaming\Rainmeter\Rainmeter.ini
DBUG (19:21:37.055) : ------------------------------
DBUG (19:21:37.055) : * EnumDisplayDevices / EnumDisplaySettings API
DBUG (19:21:37.056) : \\.\DISPLAY1
DBUG (19:21:37.056) :   Name     : Generic PnP Monitor
DBUG (19:21:37.056) :   Adapter  : AMD Radeon(TM) Graphics
DBUG (19:21:37.056) :   Flags    : ACTIVE PRIMARY (0x00080005)
DBUG (19:21:37.057) :   Handle   : 0x0000000000010001
DBUG (19:21:37.057) :   ScrArea  : L=0, T=0, R=1920, B=1080 (W=1920, H=1080)
DBUG (19:21:37.057) :   WorkArea : L=0, T=0, R=1920, B=1050 (W=1920, H=1050)
DBUG (19:21:37.057) : \\.\DISPLAY2
DBUG (19:21:37.057) :   Adapter  : AMD Radeon(TM) Graphics
DBUG (19:21:37.057) :   Flags    : (0x00080000)
DBUG (19:21:37.057) : \\.\DISPLAY3
DBUG (19:21:37.058) :   Adapter  : NVIDIA GeForce GTX 1650
DBUG (19:21:37.058) :   Flags    : (0x00000000)
DBUG (19:21:37.058) : ------------------------------
DBUG (19:21:37.058) : * EnumDisplayMonitors API
DBUG (19:21:37.058) : \\.\DISPLAY1
DBUG (19:21:37.058) :   Flags    : PRIMARY (0x00000001)
DBUG (19:21:37.059) :   Handle   : 0x0000000000010001
DBUG (19:21:37.059) :   ScrArea  : L=0, T=0, R=1920, B=1080 (W=1920, H=1080)
DBUG (19:21:37.059) :   WorkArea : L=0, T=0, R=1920, B=1050 (W=1920, H=1050)
DBUG (19:21:37.059) : ------------------------------
DBUG (19:21:37.059) : * METHOD: EnumDisplayDevices + EnumDisplaySettings Mode
DBUG (19:21:37.059) : * MONITORS: Count=3, Primary=@1
DBUG (19:21:37.059) : @0: Virtual screen
DBUG (19:21:37.059) :   L=0, T=0, R=1920, B=1080 (W=1920, H=1080)
DBUG (19:21:37.060) : @1: \\.\DISPLAY1 (active), MonitorName: Generic PnP Monitor
DBUG (19:21:37.060) :   L=0, T=0, R=1920, B=1080 (W=1920, H=1080)
DBUG (19:21:37.060) : @2: \\.\DISPLAY2 (inactive), MonitorName: 
DBUG (19:21:37.060) : @3: \\.\DISPLAY3 (inactive), MonitorName: 
DBUG (19:21:37.060) : ------------------------------

[Brian]

I see both issues.


The first issue has to do with a hard limit on bitmap size supported by the different D3D feature levels. Right now, that hard limit for D3D 11.1 is 16348.
https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-devices-downlevel-intro#feature-support-for-feature-levels-12_2-through-9_3 (see "Max Texture Dimension")
https://github.com/rainmeter/rainmeter/blob/master/Common/Gfx/Canvas.cpp#L754-L766

Note: Non-hardware accelerated graphics (using CPU WARP), has a limit of 16MP or 16777216 (16*1024*1024)

I believe we attempted to draw large images in "segments" to get around this hard limit, but obviously there is something wrong. This may take some time to fix since the original author of this piece of code isn't very active anymore.


The second issue is probably related to the first issue since both images are over the "max texture limit", but there is obviously some extra processing going on that is causing the whole thing to slow down like that.


Thanks for reporting, we will look into it!

-Brian

[Yincognito]

I see both issues.


The first issue has to do with a hard limit on bitmap size supported by the different D3D feature levels. Right now, that hard limit for D3D 11.1 is 16348.
https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-devices-downlevel-intro#feature-support-for-feature-levels-12_2-through-9_3 (see "Max Texture Dimension")
https://github.com/rainmeter/rainmeter/blob/master/Common/Gfx/Canvas.cpp#L754-L766

Note: Non-hardware accelerated graphics (using CPU WARP), has a limit of 16MP or 16777216 (16*1024*1024)

I believe we attempted to draw large images in "segments" to get around this hard limit, but obviously there is something wrong. This may take some time to fix since the original author of this piece of code isn't very active anymore.


The second issue is probably related to the first issue since both images are over the "max texture limit", but there is obviously some extra processing going on that is causing the whole thing to slow down like that.


Thanks for reporting, we will look into it!

-Brian

Ah, D3D specifications, so it is indeed a "Windows" thing, after all - I suspected that it was about some image format specifications instead, when posting, but obviously I was wrong. I too thought about suggesting breaking the image into "segments" earlier, which would then be loaded/swapped in the fast memory, but it appears Rainmeter already implements the best method to handle this (as a side note, that now explains why "playing" a Bitmap meter is very slightly not as "fluid" as using image sequences, despite memory operations normally being much faster than disk ones).

Thanks for looking into it, Brian! If it's too complicated to workaround this (I'm talking about the 1st bug here), an alternative solution could be to somehow allow multiple "rows" to be used in Bitmap meters instead of a single "row" (small height) and many "columns" (large width), if it doesn't break backward compatibility (optional options, so to speak, would be one way of compromise here). That would not require messing with the D3D specifications or migrating to a higher D3D version / requirement (my bad, just looked into it and it appears it has the same specifications for max texture dimensions, so it won't solve anything) and would allow using a texture space that is now unused. As for the 2nd bug, that is one weird effect indeed, unexpected considering the bitmap was smaller then.

It appears I'll either have to parse Rainmeter.ini to check if HA is used so I can disable the Bitmap variant in my skin, or even better, just scrap the Bitmap variant altogether since the good ol' Image meter can do the job via dynamic cropping, assuming a more balanced row/column frame layout in the image (which I already use). So, take your time with this, thankfully there are good alternatives achieving the same goal for now.