I was testing with some different tablets and had a similar problem with a Wacom Intuos 4 Model PTK-640. After digging into it, I found the cursors being reported as values that aren't handled in GHOST. The following diff fixed it for me.
Looking into it more I think that there is a programmatic approach to knowing which cursors are active according to Wintab, using WtInfo and WTI_CURSORS, which might bullet-proof this more. I'll look into this more next time I have access to a bunch of tablets.
Thu, Jul 20
Given the FSF reply and links in T48109#369234, I think we can safely close this.
Wed, Jul 19
On the other end, since '@' file is written first, would be the first one to hit permission issue, so…
Hmmm… the '@' file is a temp .blend file Blender uses to dump its binary data in, before renaming it to final file name - it avoids potentially running an existing .blend file whe you write over it.
Not sure we can do much here? It’s kind of Blender not having focus issue most likely, so it cannot handle own events, or something like that I’d guess… We need a windows dev to have a look at this, but would really no consider this as high priority issue.
Tue, Jul 18
This is definitely a challenging problem to describe. Let me give you my step-by-step.
Probably this is some issue with NTFS file junctions. What is the exact error you message get, when saving a .blend to this folder?
Mon, Jul 17
I just found that problem for a project that I'm working one. There is any solution available or hack that we can do to solve the it? I see that the first report was done around 4 years ago, and blender 2.78 still don't recognise linked folders in windows 10.
Sat, Jul 15
Yea I couldn't reproduce this on my tablet, but its a Wacom...
Hello, I am going to try to fix this.
Sat, Jul 8
I think disabling it is fine. Windows is already scaling the title bar correctly in 2.78c when you change the DPI setting.
I tried using SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2) that is available in Windows 10 version 1703, but it has the same issue as EnableNonClientDpiScaling.
If we can't find a better solution to this, I think we should automatically not call this function for Intel cards. It's only a cosmetic thing for title bars anyway.
Is it worth adding a setting to optionally bypass the call to EnableNoClientDpiScaling? Current intel chipsets can run Blender at very good speeds, a lot of notebook and tablet vendors are choosing to not even include discrete chipsets anymore. Even the iris 540 in the surface pro 4 is a credible solution for Unity and Blender.
I can confirm an issue like this with an Intel HD 4600 on Windows 10, when setting "Change the size of text, app, and other items" in the Display settings to something else than 100%. Using an NVidia GTX 1080 on the same computer shows no problem.
Tue, Jul 4
Not sure we can do much here… we need a windows dev to investigate anyway. But issue is probably a mix of driver and windows handling of tablets that conflicts with older API… Supporting ink in Blender is more of a TODO than anything else.
Mon, Jul 3
I would like to at least investigate this a little since it is a regression due to changes in Blender.
All I can say is "bummer", as it worked in 2.78c. :(
Thanks for all the thorough testing, but am afraid this demonstrate once again that issue is with Intel drivers… Not much we can do here, unfortunately, besides waiting and hoping for issue to be fixed in a future driver revision. Thanks for the report anyway.
The problem will indeed be to find some dev with said material able to reproduce the issue… :/
Thank you - I have done the following:
- Ensure both your OS and drivers are fully up-to-date (and use official GPU drivers, not those provided by windows or tablet/laptop maker).
- Try to start Blender in factory settings (--factory-startup commandline option) (this will ensure whether this is a userpref or addon issue or not).
- Try to tweak OGL settings in UserPreferences, System tab.
- Try to tweak your GPU driver settings (e.g. try different values between 'performance' and 'quality' if you have such slider, etc.).
- Try to place this dll next to your blender.exe (software OGL, will be slow, but will show whether this is a driver issue or not).
No, it doesn't work at either resolution - but the amount of empty banding is off by a different amount.
Since you mention 1920x1080 specifically, does it work correctly at the default Surface Pro 4 resolution?
Sat, Jul 1
My Blender installation on Windows 10 was done using blender-2.78c-windows64.msi
With this the thumbnails are missing on .blend files in the Windows Explorer.
Running blender.exe -R fixes the problem - but as said above, it would be nice if it was done automatically as part of the installation.
Sun, Jun 25
Works for me to. rx580 ;)
I'm a little confused now - these 3D previews come from the different blender versions (yours and official 2.78)
but obviously the bottom one, which is the experimental one, is different.
This has absolutely nothing to do with this bug, but I'd just like to know why that is
Sat, Jun 24
I doesn't contain any other stuff so it should be safe. Now that the fix is committed, tomorrow's build from builder.blender.org and 2.79 will have the fix as well.
Okay, I just tested it.
It seems to work fine and I can't see any artifacts - Yei!
I don't have a Windows machine to test, but perhaps P506 can solve it. Here's a build with that patch for testing: