WoW:UIOBJECT ScrollFrame: Difference between revisions
(Added note about ScrollFrame display glitch) |
m (Move page script moved page UIOBJECT ScrollFrame to UIOBJECT ScrollFrame without leaving a redirect) |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{widget}} | {{widget}} | ||
In many cases, ScrollFrames, and in particular the FrameXML-defined FauxScrollFrame, does more than you need. If all you are trying to accomplish is offsetting a list in an array of buttons/fontstrings, as is often the case, all you really need is a [[UIOBJECT Slider|Slider]]. ScrollFrames are for smooth pixel-by-pixel scrolling of a complete frame that is only partially visible. | In many cases, ScrollFrames, and in particular the FrameXML-defined FauxScrollFrame, does more than you need. If all you are trying to accomplish is offsetting a list in an array of buttons/fontstrings, as is often the case, all you really need is a [[UIOBJECT Slider|Slider]]. ScrollFrames are for smooth pixel-by-pixel scrolling of a complete frame that is only partially visible. | ||
Scroll frames are good for scrolling large portions of text, or a large [[UIOBJECT EditBox|EditBox]]. | |||
'''Notice''': Multiple textures, positioned one to another, may start "fidgeting" when the ScrollFrame's ScrollChild containing them is resized/moved/scrolled. And "fidgeting" may mean quite serious distortions, with textures shifting up to 3-4 pixels in an unpredictable direction. Speculation here - apparently this happens because ScrollFrames are (seemingly) created by rendering all their content onto a texture in memory, and treating the ScrollFrame's ScrollChild as a mere Texture, taking its contents from the in-memory texture using SetTexCoord. Now when the 0-1 texture coordinates suffer from precision errors, everything starts to shake. Surprisingly, though, text does NOT suffer much. Bottom line - use ScrollFrames for large images or blocks of text, but not for a large number of multi-textured relatively-positioned controls. | |||
== See also == | |||
* [[XML/ScrollFrame]] | |||
Latest revision as of 04:49, 15 August 2023
In many cases, ScrollFrames, and in particular the FrameXML-defined FauxScrollFrame, does more than you need. If all you are trying to accomplish is offsetting a list in an array of buttons/fontstrings, as is often the case, all you really need is a Slider. ScrollFrames are for smooth pixel-by-pixel scrolling of a complete frame that is only partially visible.
Scroll frames are good for scrolling large portions of text, or a large EditBox.
Notice: Multiple textures, positioned one to another, may start "fidgeting" when the ScrollFrame's ScrollChild containing them is resized/moved/scrolled. And "fidgeting" may mean quite serious distortions, with textures shifting up to 3-4 pixels in an unpredictable direction. Speculation here - apparently this happens because ScrollFrames are (seemingly) created by rendering all their content onto a texture in memory, and treating the ScrollFrame's ScrollChild as a mere Texture, taking its contents from the in-memory texture using SetTexCoord. Now when the 0-1 texture coordinates suffer from precision errors, everything starts to shake. Surprisingly, though, text does NOT suffer much. Bottom line - use ScrollFrames for large images or blocks of text, but not for a large number of multi-textured relatively-positioned controls.