Editing Foobar2000:Components/Chronial's Coverflow (foo chronflow)

{{Foobar Component Infobox
| name = foo_chronflow
| screenshot = [[Image:Coverflow.PNG|247px]]
| caption = Chronial's Coverflow
| maintainer = [http://www.hydrogenaudio.org/forums/index.php?showuser=21825 Chronial]
| stable_release = n/a
| preview_release = [http://chron.visiondesigns.de/foobar2000/foo_chronflow_v0.3.0.zip 0.3.0]
| foobar_version = 0.9.5
| use = -
| license = GPL
| website = [http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55607&view=findpost&p=559186 Author's post]
| discussion_thread = [http://www.hydrogenaudio.org/forums/index.php?showtopic=55607 Hydrogenaudio Forums]
}}

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

Sourcecode can be found here: https://github.com/Chronial/foo_chronflow

= Settings =
== Cover Display Tab ==
<!--'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''-->

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures.<br>
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu.<br>
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
 Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded.<br>
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games.<br>
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate.<br>
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

 The current version contains a bug that will only show fps info if foobar is started with this setting enabled.