Widget API < ScrollFrame

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.

See also Edit

Community content is available under CC-BY-SA unless otherwise noted.