After installing version 3.3 I have noticed that the system goes for hibernation after an initial usage of about 20 minutes and have observed that the system fan exhausting too hot air out of vents. Please help.

Regards,

ABdulMajid

Can you give us your system information first? And does going back to 3.3.2 help?

If your computer really does overheat, it would really just shut itself down immediately and not going into hibernation. If any software can ever get your computer to overheat, then you should go improve the cooling of your system.

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.

First time it really shut down but afterwards all times like 4 it is now hibernating.

TheraHedwig wrote:Can you give us your system information first? And does going back to 3.3.2 help?

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.

First time it really shut down but afterwards all times like 4 it is now hibernating.

abdulmajid wrote:

TheraHedwig wrote:Can you give us your system information first? And does going back to 3.3.2 help?

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.

First time it really shut down but afterwards all times like 4 it is now hibernating.

I am using Krita on this system since 2.5 or 2.7 until 3.2 no problem but now on 3.3 it went off then so on hibernating.

TheraHedwig wrote:Can you give us your system information first? And does going back to 3.3.2 help?

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.

First time it really shut down but afterwards all times like 4 it is now hibernating.

abdulmajid wrote:

abdulmajid wrote:

TheraHedwig wrote:Can you give us your system information first? And does going back to 3.3.2 help?

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.

First time it really shut down but afterwards all times like 4 it is now hibernating.

I am using Krita on this system since 2.5 or 2.7 until 3.2 no problem but now on 3.3 it went off then so on hibernating.

And if you go back to 3.2, does that help? Because we're rather worried your computer might instead be broken.

abdulmajid wrote:

abdulmajid wrote:

TheraHedwig wrote:Can you give us your system information first? And does going back to 3.3.2 help?

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.

First time it really shut down but afterwards all times like 4 it is now hibernating.

I am using Krita on this system since 2.5 or 2.7 until 3.2 no problem but now on 3.3 it went off then so on hibernating.

OK will revert back after uninstalling and revert to older version. thanks.

TheraHedwig wrote:Can you give us your system information first? And does going back to 3.3.2 help?

Thanks. THe specs are HP probook i3 processor, 4 GB RAM. 320 GB Win 10. External 20 inch touch screen Dell which not using but only a Wacom Bamboo.


I am using Krita on this system since 2.5 or 2.7 until 3.2 no problem but now on 3.3 it went off then so on hibernating.[/quote]
OK will revert back after uninstalling and revert to older version. thanks.[/quote]

Reverting to 3.2 helped. It is not going for shutdown or hibernation but looks like hot blowing air from vents especially when using a multi brush with 20 heads on 3000x3000 px sheet worked for 5 minutes. For sketching and inking did not misbehaved for almost 30 minutes even no hot air from vents. I also did a job to uninstall some extra resources bundles such as brushes before reverting but it did not helped and I stoped 3.3 version before shut down or hibernation. Please check the 3.3 version.

Can you use Krita 3.3 and try doing this?

From the menu bar select "Help", then "Show system information for bug reports", then copy the contents and paste them in your reply.
After that, from the menu bar select "Settings", then "Configure Krita", then on the left side select "Display", and then untick the checkbox saying "Canvas Graphics Acceleration", then test again?

alvinwong wrote:Can you use Krita 3.3 and try doing this?

From the menu bar select "Help", then "Show system information for bug reports", then copy the contents and paste them in your reply.
After that, from the menu bar select "Settings", then "Configure Krita", then on the left side select "Display", and then untick the checkbox saying "Canvas Graphics Acceleration", then test again?

It worked nicely. Well done and thanks for your help. The copied text is below:

Krita
Version: 3.3.0

OS Information
Build ABI: x86_64-little_endian-llp64
Build CPU: x86_64
CPU: x86_64
Kernel Type: winnt
Kernel Version: 10.0.15063
Pretty Productname: Windows 10 (10.0)
Product Type: windows
Product Version: 10

OpenGL Info
Vendor: Google Inc.
Renderer: "ANGLE (Intel(R) HD Graphics 3000 Direct3D11 vs_4_1 ps_4_1)"
Version: "OpenGL ES 3.0 (ANGLE 2.1.0.8613f4946861)"
Shading language: OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.8613f4946861)
Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile))
Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::SwapBehavior(DefaultSwapBehavior), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(NoProfile))
Version: 3.0
Supports deprecated functions false
is OpenGL ES: true

QPA OpenGL Detection Info
supportsDesktopGL: true
supportsAngleD3D11: true
isQtPreferAngle: true
overridePreferAngle: false
== log ==
createPlatformOpenGLContext QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile))
Basic wglCreateContext gives version 3.1
OpenGL 2.0 entry points available
GPU features: QSet("disable_desktopgl")
Disabling Desktop GL: GpuDescription(vendorId=0x8086, deviceId=0x116, subSysId=0x167c103c, revision=9, driver: "igdumd64.dll", version=9.17.10.4459, "Intel(R) HD Graphics 3000")
supportedRenderers GpuDescription(vendorId=0x8086, deviceId=0x116, subSysId=0x167c103c, revision=9, driver: "igdumd64.dll", version=9.17.10.4459, "Intel(R) HD Graphics 3000") renderer: QFlags(0x2|0x4|0x8|0x20)
Qt: Using EGL from libEGL
Qt: Using OpenGL ES 2.0 from libGLESv2
create Created EGL display 0x30b1c10 v 1 . 4
createPlatformOpenGLContext QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile))
~QWindowsEGLStaticContext Releasing EGL display 0x30b1c10
== end log ==

Hi, I don't know beans about Krita, just evaluating it right now. I do know a little about historical OpenGL issues on Windows. I'm willing to bet you have an OpenGL implementation with some feature that is very sub-par and poorly performing. It could, for instance, throw the rendering through a software rasterizer, or encounter some horrific Memory Barrier instruction over and over again. The net effect on a poorly tested, seldom used, poorly supported code path, is that your CPU usage goes through the roof. It is probably your CPU usage going completely bonkers that is causing your computer to overheat and shut down. It is also possible that your CPU and GPU are linked together at the driver level sharing resources, so that when the GPU can't handle stuff, the CPU becomes burdened as well.

What probably happened between Krita 3.2 and 3.3, is it used an OpenGL feature or code path it wasn't previously using. This turns out to be a "serious sore spot" on your machine, causing it to keel over and die. That is where the devs or other interested parties, should look for solutions to your problem.

How do I know about stuff like this? Because I've got 2 business class laptops from 2008 that are running Windows 10. One of them us such junk, that it doesn't even have an OpenGL 2.0 implementation available! Yep, it'll only run a 1.x interface. It has some kind of Intel integrated graphics in it, and Intel made seriously shoddy drivers back then for OpenGL. My other machine has an AMD chip in it, so it does present a nominal OpenGL 3.3 interface. Both of these machines are only DX10 class HW though, so anything that tries to hammer them with DX11 shader capabilities can be really really bad. Some demos of stuff will run but they're slooooooow, measured in seconds per frame.

Old clunker machines will often run DX11 stuff just fine, because the marketplace was bothering to implement decent DX9 / DX10 support back in the day. Whereas, historical OpenGL driver support, has been abysmal. That's why professional game developers mostly won't use it, too many angry customers with broken games. That's the reality of trying to do OpenGL anything on Windows. It's not a good fit to platform, and it's also a dying API. Microsoft made it so, but it is what it is.

well, if opengl is the problem, setting display acceleration to use 'Angle' should help.

We won't be going away from OpenGL in the near foreseeable future for the sheer reason it is the only cross platform API that works on the majority of consumer devices. Vulkan driver support is still too young, on top of none of us being graphics card programmers and thus not be able to make any good use of the API. Supporting propriatary APIs without an abstraction like like Angle is even more unplausible.

And on top of that, Vulkan is never going to be a cross-platform API. Windows doesn't need it, it has DX12. Apple doesn't want it, it has and will be pushing Metal. Vulkan is frankly an API solution in search of a problem. I'd like to believe it might survive on Linux and not suck, but I have no hope or faith. I did a 3 year stint trying to be a Linux developer, back when the Steam Machine looked like it could potentially be a thing. It wasn't, and isn't. Finally after seeing no progress in that community / universe I gave up and went back to Windows. Vulkan is simply a reaction to the fact that OpenGL is dying and nearly dead. Linux is a weak graphics platform, definitely in terms of games, arguably in terms of other apps. So there is not going to be quality Vulkan anything.

Not long ago, NVIDIA had categorically refused to work on a Wayland display server, preferring the historical X11 cruft. Playing catch-up now, I see that NVIDIA has implemented some proprietary Wayland something-or-other, that nobody else does. So now there's consternation about whether FLOSS types should support NVIDIA's shenanigans. Not that many years ago, Linus Torvaldis famously gave NVIDIA the middle finger. In this kind of environment, there is just no reason to expect high quality graphics stuff to emerge. It "might sort of work and clunk along".

Vulkan will stew in the graphics poor Linux environment, and nobody else will care. DirectX will move on, Metal will move on. The market will be more fragmented. Cross-platform developers will always pull their hair out, trying to decide what to do about it. I can see why you'd stick to OpenGL, even if it's no good on various machines, because nothing is ever going to be good on the majority of the machines. Unless by "majority" you decide it's Windows in the real world.

Even Windows developers have to worry about threats from Microsoft itself, i.e. Windows Universal Platform vs. traditional Desktop development. MS has a long history of "flavor of the year" APIs that prove stillborn. They churn things to maintain control. Give all those devs another hamster wheel to run on, to stay "current".