What should happen to disabling "Canvas Graphics Acceleration" and QPainter canvas
Open, Needs TriagePublic

Description

To complement T14865 which handles the OpenGL support in Krita, I thought we should have a task for non-OpenGL support.

  • Shall we make sure that Krita really does not use OpenGL for the rest of the UI when "Canvas Graphics Acceleration" is disabled?
  • Do we intend to keep the QPainter canvas alive for the foreseeable future?
  • Do we want to keep it feature-complete?
    • The QPainter canvas is already missing some features like wraparound mode and high-DPI support.
  • Are we going to port the QPainter canvas to QtQuick2 too? (T13339)
alvinhochun created this task.EditedFeb 13 2022, 3:53 PM

Shall we make sure that Krita really does not use OpenGL for the rest of the UI when "Canvas Graphics Acceleration" is disabled?

Currently, even if you disable "Canvas Graphics Acceleration" which switches to the QPainter canvas, Krita is still rendered in OpenGL. It's very easy to check on Windows -- pay attention to the GPU percentage and the GPU Engine column of Krita in Task Manager and resize the Krita window. If it ever rises above 0% and/or it shows "GPU 0 - 3D" it means the window uses an OpenGL (or ANGLE) surface. This is because of the existence of 1) the touch docker using QQuickWidget, and 2) the small color selector using QOpenGLWidget, which both enable OpenGL composition for the top-level QWidget.

This means disabling "Canvas Graphics Acceleration" cannot 100% bypass or rule out crashes or misbehaviours caused by a bad graphics driver.

(Note that this does not mean the QPainter canvas will use the OpenGL paint engine. In fact normal widgets are still painted in software, which Qt composites onto the window by uploading it to the GPU memory as a texture.)

There is a way to fix this, when "Canvas Graphics Acceleration" is disabled:

  1. Switch to the Qt Quick Software Adaptation by calling QQuickWindow::setSceneGraphBackend, and
  2. Block loading of the small color selector.

(But then after toggling this option the user must restart Krita for the changes to really apply.)

rempt added a subscriber: rempt.Feb 14 2022, 4:07 PM
Shall we make sure that Krita really does not use OpenGL for the rest of the UI when "Canvas Graphics Acceleration" is disabled?

Yes

Do we intend to keep the QPainter canvas alive for the foreseeable future?

Yes

Do we want to keep it feature-complete?  QPainter canvas is already missing some features like wraparound mode and high-DPI support.

No

Are we going to port the QPainter canvas to QtQuick2 too? (T13339)

No

Are we going to port the QPainter canvas to QtQuick2 too? (T13339)

No

I guess we don't need to decide on this so early. We can wait until we have a QtQuick2 OpenGL canvas working in full, which will probably take a long time...

In the meantime I will avoid breaking the QPainter canvas with my experiments.