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
MediaPortal 1 Plugins
Popular Plugins
Moving Pictures
Need help: MP 1.0.0 random crash in Vista
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="tourettes" data-source="post: 380780" data-attributes="member: 10858"><p>Not sure. Its just a "hack" to try to delay the texture unloading on C++ side (usually I won't touch the C# side code <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />) fontEngine.dll is pretty stupid component (no logic inside it), it mainly exports some low level functions to C# side. So all the actual locking logic should go into C# side (I just added some safe guards as MP was sometimes panicing on my HTPC). Not sure if it has some side effects like rendering clitches etc. when MP side is not playing nicely.</p><p></p><p>...so, the C# should be handling the locking correctly and make sure that when the rendering pass is ongoing textures & surfaces are left alone in the fontEngine.dll side. All changes must be done pretty carefully as it its easy to introduce some pretty well "hidden" dead locks (as you see that the timing has been working on luck basis for few years already with pretty small odds to get MP to crash to desktop <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />)</p><p></p><p>The locking must be done on rendering pass basis (as one to me it looks like one rendering call to the fontEngine.dll can cause multiple textures to be rendered).</p></blockquote><p></p>
[QUOTE="tourettes, post: 380780, member: 10858"] Not sure. Its just a "hack" to try to delay the texture unloading on C++ side (usually I won't touch the C# side code :)) fontEngine.dll is pretty stupid component (no logic inside it), it mainly exports some low level functions to C# side. So all the actual locking logic should go into C# side (I just added some safe guards as MP was sometimes panicing on my HTPC). Not sure if it has some side effects like rendering clitches etc. when MP side is not playing nicely. ...so, the C# should be handling the locking correctly and make sure that when the rendering pass is ongoing textures & surfaces are left alone in the fontEngine.dll side. All changes must be done pretty carefully as it its easy to introduce some pretty well "hidden" dead locks (as you see that the timing has been working on luck basis for few years already with pretty small odds to get MP to crash to desktop :)) The locking must be done on rendering pass basis (as one to me it looks like one rendering call to the fontEngine.dll can cause multiple textures to be rendered). [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
Popular Plugins
Moving Pictures
Need help: MP 1.0.0 random crash in Vista
Contact us
RSS
Top
Bottom