WoW:UIOBJECT ScrollFrame: Difference between revisions
No edit summary |
mNo edit summary |
||
| 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. | ||
| Line 8: | Line 7: | ||
'''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. | '''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]] | |||
Revision as of 06:52, 14 February 2015
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.