home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Quality Assurance
Bugtracker Feed
0003291: Rework MediaPortal texture clipping
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="MediaPortal-Bot" data-source="post: 693631" data-attributes="member: 48617"><p>This issue addresses a bug/conflict between the use of viewport manipulation for texture clipping (existing MediaPortal capability) and the introduction of new capabilities (such as image masking).</p><p></p><p>MediaPortal relies on texture clipping for presentation of nice UI features including smooth scrolling on and off the screen against a straight edge. The clipping capability in MediaPortal is completely managed by setting the D3D viewport. Some functions of the FontEngine (the primitive texture drawing routines) read the viewport settings passed to it and perform computational (or manual) clipping by adjusting the extent of the texture that should be rendered. This works fine for some of the drawing routines in the FontEngine but not for others. The design of the FontEngine provides two basic routes to D3D primitive drawing functions; (1.) FontEnginePresentTextures and FontEngineDrawText3D, and (2.) via several other FontEngineDraw... functions. The basic difference between these functions (1.) vs. (2.) is that the (1.) functions render lists of textures and the (2.) functions render a specific (passed in ) texture. The flexibility of the (2.) functions allows for manipulation of the graphics pipeline (hardware) on a per texture basis (this is nice for doing more complex rendering easily such as managing the motion of cards in a cover flow list). When calling (1.) functions the viewport must be opened up to be coincident with the whole screen (because the FontEngine stores a list of textures to present but does not maintain clip information for any of the textures in the list). When calling (2.) functions the viewport only used to obtain the rectangle values to perform the manual clipping; the viewport is otherwise opened up to be coincident with the screen for drawing. This casual (or convenient) use of the viewport in MediaPortal prevents the general exploitation of the rendering pipeline for hardware accelerated, complex rendering functions (like texture masking). It is recommended that the capability of MediaPortal to perform texture clipping be redesigned to use hardware accelerated clipping where possible (by using the D3D render state D3DRS_SCISSORTESTENABLE and associated apparatus).</p><p></p><p><a href="http://mantis.team-mediaportal.com/view.php?id=3291" target="_blank">http://mantis.team-mediaportal.com/view.php?id=3291</a></p><p></p><p><a href="http://mantis.team-mediaportal.com/view.php?id=3291" target="_blank">Open the issue in Mantis...</a></p></blockquote><p></p>
[QUOTE="MediaPortal-Bot, post: 693631, member: 48617"] This issue addresses a bug/conflict between the use of viewport manipulation for texture clipping (existing MediaPortal capability) and the introduction of new capabilities (such as image masking). MediaPortal relies on texture clipping for presentation of nice UI features including smooth scrolling on and off the screen against a straight edge. The clipping capability in MediaPortal is completely managed by setting the D3D viewport. Some functions of the FontEngine (the primitive texture drawing routines) read the viewport settings passed to it and perform computational (or manual) clipping by adjusting the extent of the texture that should be rendered. This works fine for some of the drawing routines in the FontEngine but not for others. The design of the FontEngine provides two basic routes to D3D primitive drawing functions; (1.) FontEnginePresentTextures and FontEngineDrawText3D, and (2.) via several other FontEngineDraw... functions. The basic difference between these functions (1.) vs. (2.) is that the (1.) functions render lists of textures and the (2.) functions render a specific (passed in ) texture. The flexibility of the (2.) functions allows for manipulation of the graphics pipeline (hardware) on a per texture basis (this is nice for doing more complex rendering easily such as managing the motion of cards in a cover flow list). When calling (1.) functions the viewport must be opened up to be coincident with the whole screen (because the FontEngine stores a list of textures to present but does not maintain clip information for any of the textures in the list). When calling (2.) functions the viewport only used to obtain the rectangle values to perform the manual clipping; the viewport is otherwise opened up to be coincident with the screen for drawing. This casual (or convenient) use of the viewport in MediaPortal prevents the general exploitation of the rendering pipeline for hardware accelerated, complex rendering functions (like texture masking). It is recommended that the capability of MediaPortal to perform texture clipping be redesigned to use hardware accelerated clipping where possible (by using the D3D render state D3DRS_SCISSORTESTENABLE and associated apparatus). [url]http://mantis.team-mediaportal.com/view.php?id=3291[/url] [url=http://mantis.team-mediaportal.com/view.php?id=3291]Open the issue in Mantis...[/url] [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Quality Assurance
Bugtracker Feed
0003291: Rework MediaPortal texture clipping
Contact us
RSS
Top
Bottom