Reply to thread

Message

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).

<blockquote data-quote="tourettes" data-source="post: 380780" data-attributes="member: 10858">Not sure. Its just a &quot;hack&quot; 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&nbsp; &nbsp; :)" 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....so, the C# should be handling the locking correctly and make sure that when the rendering pass is ongoing textures &amp; 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 &quot;hidden&quot; 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&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />)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).</blockquote>

[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]