I am using Manim.
Every time I render the animation, this message came out in the terminal
Should this concern my system?
(process:8884): GLib-GIO-WARNING **: 00:03:23.424: Unexpectedly, UWP app AcerIncorporated.PredatorSenseV30_3.0.3138.0_x64__48frkmn4z8aw4' (AUMId AcerIncorporated.PredatorSenseV30_48frkmn4z8aw4!CentenialConvert') supports 1 extensions but has no verbs
The file is perfectly rendered but it does not open automatically when I render it in 480p
If I will render the animation in 1080p, the warning still comes out first and the video runs automatically.
This happens to me as well when I render animations on Manim. It made no impact on my machine whatsoever, so I don't think you should be concerned.
Related
My vuejs nuxt portfolio(https://gunjankadu.com/)is not opening on ios phones but working flawlessly on all other devices. On IOS devices only a red spinner is shown and nothing more.
What can be done?
A script "tag.js" took time to load, which I have currently disabled but still not working.
I had a look on your application and found out two problems.
First was about regular expressions, It seems Safari doesn’t support look behind yet. One alternative would be to put the / that comes before in a non-captured group, and then extract only the first group (the content after the / and before the #).
/(?:\/)([^#]+)(?=#*)/
And second is about The minimal-ui viewport property that you can find out more here
Look at all your js/vue files especially in store. And see if any variable used is not imported. Nuxt in SPA mode doesn't detect those kind of errors and surprisingly the UI gets stuck on loading only on iOS. Very weird but scratched my brain over it for a day.
I’m currently running into an issue where I’m trying to load a Draco compressed model using the Draco Loader of threejs on mobile browsers and it seems to hard crash during the call to the `.load method. IOS Safari not and Chrome version 88.0.4324.93 on an Android - Pixel 2 XL are the ones I’ve tested so far. The exact same models seem to render completely fine on web browsers with no issues.
This is a screenshot of the error I’m receiving which states memory access out of bounds
RuntimeError: memory access out of bounds
at <anonymous>:wasm-function[377]:0x18a28
at <anonymous>:wasm-function[358]:0x170b9
at <anonymous>:wasm-function[354]:0x16f17
at <anonymous>:wasm-function[446]:0x21f40
at <anonymous>:wasm-function[323]:0x1371f
at <anonymous>:wasm-function[23]:0x2cb1
at emscripten_bind_Decoder_DecodeBufferToMesh_2 (<anonymous>:wasm-function[119]:0x934e)
at a._emscripten_bind_Decoder_DecodeBufferToMesh_2 (blob:https://bdd35c37d00a.ngrok.io/95a82b20-81cc-451e-a630-f47694de7a0f:51:560)
at g.DecodeBufferToMesh.g.DecodeBufferToMesh (blob:https://bdd35c37d00a.ngrok.io/95a82b20-81cc-451e-a630-f47694de7a0f:92:54)
at decodeGeometry (blob:https://bdd35c37d00a.ngrok.io/95a82b20-81cc-451e-a630-f47694de7a0f:189:29)
I’ve tried adding console logs to the onProgress, onLoad, and onError callbacks. The onProgress seems to fully complete but after that, before the onLoad callback can run, it crashes and the onError callback isn’t called either.
Anyone have any ideas on how to go about solving this?
I'm using the Microsoft sample DX11VideoRenderer to render real time video in Windows 10. When I run just one stream, the video looks great. However when I run more than 4 or 5 streams, some of the video in their respective windows start blanking out intermittently. The effect can be over just a portion or all of each video window.
Also I get a few intermittent errors from this function call in my log file:
hr = pVideoContext->VideoProcessorBlt(m_pVideoProcessor, pOutputView, 0, 1, &StreamData );
The error returned is: E_INVALIDARG One or more arguments are not valid 0x80070057
I'm only using the Presenter.cpp and display.cpp modules of the DX11VideoRenderer in my code. The source is located at:
DirectX video rendering sample
My initial suspicion at this stage is that DXVideoRenderer may not be thread safe. I found this information about multithreading: Introduction to Multithreading in Direct3D 11 which states:
While the use of a device context (ID3D11DeviceContext) is not thread-safe, the use of a Direct3D 11 device (ID3D11Device) is thread-safe.
But it seems that since I'm using separate instances of the CPresenter class for each window, there should not be a problem with ID3D11DeviceContext not being thread safe because each window should have it's own instance of ID3D11DeviceContext.
Does anyone have any experience or ideas about this DX11VideoRenderer software sample and what might be causing this problem?
Thank you!
-UPDATE-
I have been able to duplicate the problem with just one window so it no longer appears to be a threading issue. If I manually resize the window many times I can sometimes get the video in the window to flicker. When this happens I see in my log that the same function call to VideoProcessorBlt() had a failure with the same return code, E_INVALIDARG.
If I manually resize the window many times I can sometimes get the video in the window to flicker. When this happens I see in my log that the same function call to VideoProcessorBlt() had a failure with the same return code, E_INVALIDARG.
This behaviour is not documented by Microsoft.
The problem is the same with DirectX9, but the error occurs with IDirect3DDevice9::Present, just after VideoProcessBltHD.
The HRESULT code is 0x88760872, and 0x88760872 is not documented.
So when resizing window, the error can occur.
See H264Dxva2Decoder :
In Dxva2Renderer.cpp, check for HANDLE_DIRECTX_ERROR_UNDOCUMENTED.
The strategy I choosed is to pause the video if playing (see WindowsFormProc and WM_ENTERSIZEMOVE/WM_SYSCOMMAND),
also, this avoid flickering.
Doing this, the error disappears.
PS: normally this error can be safely ignored.
I think this error is just there to tell you that when the window is resized, the underlying API is struggling to synchronize the DirectX presentation with your HWND, which changes size quickly.
I have installed fresh Arch Linux with linux-ck and awesomewm. After that I have installed google-chrome and started it. Everything works well, but if I open other application (chrome lose focus) and then got back to the chrome, it freezes. Mouse cursor works as expected (cursor changes after hovering link, input field, etc) but view is not updated.
Everything works well again if I change desktop to the second and go back to the first again (mod+2, mod+1). Chrome works, responses etc well.
I bet this issue has something in common with hardware acceleration. If I run some game (steam), lose focus, get back to the game - it shows last rendered screen before focus has been lost (sound is ok, game is responsible but does not update screen).
I use nvidia. Do I need some extra configuration to handle it ?
You want to disable "Use hardware acceleration when available" in Chrome settings.
For me, disabling hardware acceleration as Alex pointed out solved the issue. This bug has been brought forward before in awesome's issues GitHub page.
Apparently, the problem is not awesome. Graphics drivers might be involved but the main suspect seems to be the compositing manager. Running awesome with the "--no-argb" flag and disabling the comp manager seems to solve the problem.
The problem was xcompmgr which caused "freezing" view. I switched it to unagi and all of the problems have gone.
In our applications, we display a webpage in a TWebBrowser component.
After installing IE8, some of our application started to stop responding on closedown.
We have found the following to be true:
It only freezes if the webpage have been shown
Which application that freeze, depends on what url is shown. If we switch url between two applications, the working application freeze, and the other close down normaly.
Have anybody experienced something similar?
One url that freeze the application: http://www.finale.no/arsoppgjor
One url that does not freeze the application: http://www.finale.no/avstemming_meldinger
** UPDATE **
We have now found a pattern, a pattern thats kind of strange, but it's no less a pattern...
When the page that we display contains images, and the images is scaled, our application freezes. For now, we will just remove or rescale images.
Long shot: did you put OleInitialze OleUinitialze in your app?
Sounds like there may be a thread deadlocking. I would run SysInternals Process Explorer on your application when it is deadlocked. Add a reference to the Microsoft symbols (Options -> Configure symbols). Now double-click the process, and choose the Threads tab. Look through IE's threads and see if you can figure out if one is deadlocking and why, especially from the stack.
I recommend doing this in Process Explorer instead of the Delphi debugger since Process Explorer understands the Microsoft symbols.