Bug 411579

Summary: GPU accelerated terminal
Product: [Applications] konsole Reporter: agilob <kdebug>
Component: generalAssignee: Konsole Developer <konsole-devel>
Status: REPORTED ---    
Severity: wishlist CC: jlp, kde.podagric, kiril, mglb, uwu
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: attachment-10435-0.html

Description agilob 2019-09-04 06:30:25 UTC
Would it be massive amount of work to support GPU acceleration in Konsole/Yakuake the way Kitty does it?

https://sw.kovidgoyal.net/kitty/
Comment 1 tcanabrava 2019-09-04 07:57:33 UTC
Created attachment 122482 [details]
attachment-10435-0.html

Yes, massive.
basically we would need to rewrite the file TerminalDisplay.cpp - that
takes care of painting everything on the screen.
That file is huge, and it uses many things within Qt to make it easier -
things that don't exist in the OpenGL world.

If you want to try - if you have any knowledge in OpenGL, please give it a
try. We need more people trying to touch code.

Tomaz


On Wed, Sep 4, 2019 at 8:30 AM agilob <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=411579
>
>             Bug ID: 411579
>            Summary: GPU accelerated terminal
>            Product: konsole
>            Version: unspecified
>           Platform: Other
>                 OS: Linux
>             Status: REPORTED
>           Severity: wishlist
>           Priority: NOR
>          Component: general
>           Assignee: konsole-devel@kde.org
>           Reporter: kdebug@agilob.net
>   Target Milestone: ---
>
> Would it be massive amount of work to support GPU acceleration in
> Konsole/Yakuake the way Kitty does it?
>
> https://sw.kovidgoyal.net/kitty/
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
Comment 2 Mariusz Glebocki 2019-09-05 12:59:13 UTC
I was thinking about porting TerminalDisplay to QtQuick scenegraph some time ago. In current implementation things are made directly with pixels in mind, there is no caching, and the code is pretty messy (rendering and related features logic mixed together). Lots of work, and I guess first we should need to at least:

* Separate logic and rendering (i.e. selection, URL and file name underlining, etc);
* Store screen objects (cells, lines, ...) as objects with render cache. In current implementation the text is rerendered constantly.

Bonus points for abstract rendering backend and keeping old (working) and new (partially working) implementation in master.

Performance-wise, Kitty is not so fast when using many different characters (like in the `tests/UTF-8-demo.txt` file). Character cache should make Konsole close to Kitty, i.e. less than 2x slower when scrolling file with latin letters in `less` (it is something about 20x now).
Comment 3 fire f. 2019-12-17 17:11:05 UTC
I installed kitty but I cannot see the point. KDE is well advised not to waste effort into such an endeavour like kitty.