CSS3 animation works fine for Opera Firefox and Safari in WIN7 WINXP Ubuntu 12.04 and Debian Squeeze. WIth Chrome it's fine under WIN 7 (Chrome 21.1.1180.89m )and Ubuntu12.04. (21.1.1180.89) but not using same versions under WINXP and Debian Squeeze).
See demo site http://www.hiddenwell.org.uk which contains simple example (view source shows the code).
Object is to move one sentence (and rotate the other) when hovering over the given words.
In Win XP and Debian the first time I "hover" - nothing happens - but a second "hover" activates the animation. All then fine until cache refreshed when the problem starts again. With the other browsers listed and also Chrome when using WIN7 and Ubuntu - it all works fine first time.
Identical situation arises with another more complex animation which starts on page loading. Here I use the #keyframes function to drive the animation. In this instance for Chrome (WIN XP and Debian) the screen freezes and I need to "refresh" to get animation. It works first time in all other scenarios listed.
Anyone any ideas??
Issue is resolved with the beta version of chrome now available for WIN XP and Debian Squeeze - i.e. version 23.0.1271.17 beta.
Thanks to the Chrome team for sorting this.
I'll leave my mini-demo on my website for a week or so - so others can see the effect.
(Issue is also resolved with more complex animation discussed above - I can now push on developing another website where I hope to use latest CSS3/animation techniques)
Related
In my settings, I clearly have my screen setup to 200% like so:
When I worked on my Qt application earlier, it would properly follow that setup.
Somehow, I changed a something and now it always appears at 100%. That makes it difficult to read the text.
What option(s) would Qt have that would turn that feature off?
I have other Qt applications that still work as expected, so I'm really thinking that's something I did. Maybe a widget I added? Or a call I make? I just have no idea what it could be so looking at my changes doesn't help at the moment.
One thing I added recently is a QSvgWidget, but even if I remove it, it still doesn't work. Another thing I've notice is that the OS (Ubuntu 18.04) updated the desktop themes. But I don't think that happened at that time.
UPDATE:
This seems to be generalized. I just upgraded my OS. The VirtualBox snap was updated and now the window also appears small (i.e. ignores the High DPI setup). So it must be an OS thing (i.e. a library that was updated and it breaks the Qt High DPI feature).
Okay! I got the answer to that one in my situation.
Whenever nvidia sends a new version of their driver, my X11 session continues to work, but OpenGL is not accessible anymore. There must be something in Qt that decides to use OpenGL and since it (silently) fails opening a connection, it falls back to "no DPI scaling capability".
After a reboot, everything is back to normal and zooms in and out as expected in my app and also the VirtualBox window.
VT-x option is missing Surface Laptop 3 BIOS menu(Intel i7-1065G7 procesor), without this VT-x enabled, I cannot run any virtualization on Windows. Anyone encountered the same problem and know how to fix?
Bit late on the response so I dont know if you have worked this out already, but it might help someone else. I also have a Surface Laptop 3 but with an AMD CPU etc. Virtualisation was also missing on my BIOS. My issue was that when using Oracle VirtualBox, the 'Start' opting to begin installing Ubuntu was 'grayed out' or unable to be selected. After searching around, all I needed to proceed with installing Ubuntu was to do what this guide says.
Essentially I just searched in the Windows taskbar 'Turn Windows features on our off'. Here I was able to enable 'Virtual Machines Platform'. I also enabled Windows Hypervisor Platform although I am not sure if this is necessary. Restarted the system and I was able to proceed and install Ubuntu through VirtualBox! Hope this helps!
I found a little option using the Oracle Virtual Box for the Intel version of your Surface!
In the Task Manager, under Performance, you can check that virtualization is disabled. Just follow my easy steps:
Run VirtualBox as an administrator
Create new virtual machine (it doesn't matter what you choose)
Run it for the first time
Go to Machine Settings > System > Processor—as you can see, it is set to a default of 1
Change the number from one core to more than one and somewhere on the bottom side of the GUI you could see an attention icon that says something like
virtualization off. If you save these setting it will be automatically turned on
Just press OK and voila! It will be turned on!
Now when I type this response I checked too if it is enabled in Task Manager and it was, so yeah!
I have an application developed with Qt3D (which uses OpenGL) by Qt 5.11.3 and Xcode 9.4.1 build tools. App runs fine on Linux and Windows, but on macOS Retina display (10.14, Mojave), I observe:
There are two workarounds for the above observation:
Set Retina display to full native resolution (microscopically small) then open app which seems to look and function correctly. Then lower the resolution to something usable and app continues to work properly
Get info of the app and check the open in low resolution checkbox like this image from a website:
I have studied similar questions but the posted solutions look more like a hack. And my app is a complex one, I cannot just simply multiply everything by a ratio. Is there any other solution for this? How can I force my app to open in low resolution on macOS, already asked here? Thanks.
I'm developing a small video capture library on top of videoInput (a thin wrapper around DirectShow) and lately I encountered a tricky issue.
The library captures and saves video frames to its internal format, using code to the effect of this:
if (VI->setupDevice(m_deviceIndex, width, height)) {
//... checks for frame size etc
//...
auto pixels = VI->getPixels(m_deviceIndex, true, true);
}
This code was built in VS 2017 using vc140/sdk8.1 and it worked fine on a range of different machines running Windows 7, 8.1 and 10, which included typical office desktops and laptops, several development machines, a highly restrictive production desktop and VirtualBox guests.
Then we discovered that on one Windows 7 computer videoInput yields black frames (null pixels), even though the camera itself works properly with other applications. We tested several different camera models to the same effect.
I built DirectShow examples from official Microsoft repository and discovered that on startup the samples fail with hr=0x80070005 error (access denied), regardless of running in elevated mode. Here's where the error occurs (amcap.cpp, line 787).
Since official samples supposedly should work out of the box, I suspected that there might be a compatibility bug in later versions of SDK/MSVC and tried compiling with VS 2010, but that didn't help. I also tried different capture back-ends, using Windows Media Foundation example from the same repository, as well as OpenCV with ffmpeg - all to the same effect.
Then we discovered another machine, running Windows 10, which had exactly the same problem, indicating that this is not an issue of backwards compatibility. Meanwhile, the same builds were working fine on my test machines, and third-party applications like Webcamoid were working fine on the problematic PCs.
My best guess is that there's some kind of compatibility flag or permission which has to be granted, since the camera works just fine with third-party software, but I have no idea where to look for them, and Windows 7 doesn't have camera permission settings to begin with, if I'm not mistaken.
Now, does anyone have any idea what on Earth might be wrong? I would greatly appreciate any advice.
Thank's.
Problem solved.
The problem turned out to be due to Kaspersky Endpoint Security, which has an option to restrict video streaming for unknown applications. This is why camera apps from the Store worked fine (they were trusted by default), and our application didn't.
Caveat emptor.
I've been trying to research why certain compatibility features differ based on operating system so I can program a patch. I'm using the compatibility settings in the registry for Windows 95 to run a game (that of which the game was produced on) in each system. In Windows XP, the game runs perfectly. None of the scenes lag, and the sound works just as well as the scenes. I'm unsure of how it runs in Windows Vista, but in Windows 7 & 8 the compatibility feature breaks the game. I used a VM to run XP, but that doesn't effect the game's playability; real XP users have tested it. Whenever I play the game using the Win95 setting for compatibility in 7 & 8, everything lags. The music doesn't slow down during gameplay, but the graphics do. During cutscenes, they literally break. Everything pixelates, white noise and static increases volume, and the video lags every two seconds.
I therein tested it in Ubuntu Linux via WINE, and it runs better than it does in XP. I just had to use the alsa sound driver. What changed? If so, is it programmatically fixable? I'm using an amalgamation of C++, Batch and Java.
If it is necessary, the video game is entitled "The Neverhood."
Thanks.
The compatibility feature available in the shell is just scratching the surface of the "Application Compatibility" subject in Windows.
There is a tool called "Microsoft Application Compatibility Toolkit (ACT)" (that exist since Windows XP exist I believe) that has much more to offer, so maybe that can help.
For example here are some compatibility settings for Graphics Control Issues
I currently play "The Neverhood" on Win7 x64 without any visual problem, you are right when I played on Win7 for first time (4 years ago) was a headache and a little tricky to do the correct compatibility flags for each win version but finally I wrote this reg code for Win7 and worked for me while 4 years, sure it will work for you too:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Folder\\nhc.exe"="# WIN95 256COLOR 640X480 DISABLEDWM"
Where "C:\\Folder\\nhc.exe" of course is the path to your Neverhood. (Notice the double backslashes)
that flags means: Change Display color to 256 colors, change display resolution to 640x480, disable Themes service (DWM Service).
I hope this help you.
This may not answer the question directly, but if you want to improve performance of The Neverhood, change the compatibility to run in Windows 95 - then switch all other options ON, except the bottom three. This helps to make the game as fast and smooth as possible.