You could map the framebuffer into user-space and draw on it with loads/stores, instead of read/write system calls on sockets (the end result of GTK+ function calls is normally talking to the X server over a socket).
Or there are various libraries that allow more or less direct access to video RAM and video modes when your program is running on a virtual console with no X server (or other display server like Wayland).
Changing video modes will normally still require a system call, but you can load/store to video RAM. Different libraries presumably have different ways for dealing with vsync / double-buffering / whatever.
This isn't necessarily faster or better: modern graphics cards are much more than dumb framebuffers. They have GPU hardware that can accelerate graphics operations, and storing directly to video RAM doesn't take advantage of it.
But if you really want to play around with direct access to video RAM, those links should be a good starting point for making it happen in user-space on a virtual console under Linux, with hopefully less risk of locking up the whole machine when your program has a bug.
(Be ready to SSH in from another machine and kill your process + chvt, though. And make sure you enable the magic SysRQ keys for killing all processes on the current console, and for "unRaw" keyboard input.
Disclaimer: I have not personally written software that does this, but there are some examples like FBI (framebuffer image viewer). I have recovered the console with ssh and/or SysRQ without rebooting after using buggy software and/or buggy drivers, though.
发布评论
评论（2）
您需要：
You'll want:
如果你想进入“低级别”，有（或曾经有）https://en。 Linux + XFree86（现在称为 X.org）上的 wikipedia.org/wiki/Direct_Graphics_Access。
您可以将帧缓冲区映射到用户空间并通过加载/存储对其进行绘制，而不是在套接字上进行
read/write系统调用（GTK+函数调用的最终结果是通常通过套接字与 X 服务器通信）。或者，当您的程序在没有 X 服务器（或其他显示服务器（如 Wayland））的虚拟控制台上运行时，有各种库允许或多或少地直接访问视频 RAM 和视频模式。
https://en.wikipedia.org/wiki/Virtual_console#Interface 提及DirectFB，DRI、SDL 和旧的SVGALib。
更改视频模式通常仍然需要系统调用，但您可以加载/存储到视频 RAM。不同的库可能有不同的方式来处理垂直同步/双缓冲/其他。
这不一定更快或更好：现代显卡不仅仅是愚蠢的帧缓冲区。它们拥有可以加速图形操作的 GPU 硬件，但直接存储到视频 RAM 并不能利用它。
但是，如果您确实想尝试直接访问视频 RAM，那么这些链接应该是一个很好的起点，可以让您在 Linux 下的虚拟控制台上的用户空间中实现这一点，并且希望可以降低在您使用时锁定整个计算机的风险。程序有一个错误。
（不过，请准备好从另一台计算机进行 SSH 并杀死您的进程 + chvt。并确保启用神奇的 SysRQ 键来杀死当前控制台上的所有进程以及“unRaw”键盘输入。
免责声明：我有 不是个人编写的软件可以做到这一点，但有一些例子，例如FBI（帧缓冲图像不过，在使用有问题的软件和/或有问题的驱动程序后，我已经使用 ssh 和/或 SysRQ 恢复了控制台，而无需重新启动。
If you want to go "low level", there is (or used to be) https://en.wikipedia.org/wiki/Direct_Graphics_Access on Linux + XFree86 (now called X.org).
You could map the framebuffer into user-space and draw on it with loads/stores, instead of
read/writesystem calls on sockets (the end result of GTK+ function calls is normally talking to the X server over a socket).Or there are various libraries that allow more or less direct access to video RAM and video modes when your program is running on a virtual console with no X server (or other display server like Wayland).
https://en.wikipedia.org/wiki/Virtual_console#Interface mentions DirectFB, DRI, SDL and the old SVGALib.
Changing video modes will normally still require a system call, but you can load/store to video RAM. Different libraries presumably have different ways for dealing with vsync / double-buffering / whatever.
This isn't necessarily faster or better: modern graphics cards are much more than dumb framebuffers. They have GPU hardware that can accelerate graphics operations, and storing directly to video RAM doesn't take advantage of it.
But if you really want to play around with direct access to video RAM, those links should be a good starting point for making it happen in user-space on a virtual console under Linux, with hopefully less risk of locking up the whole machine when your program has a bug.
(Be ready to SSH in from another machine and kill your process + chvt, though. And make sure you enable the magic SysRQ keys for killing all processes on the current console, and for "unRaw" keyboard input.
Disclaimer: I have not personally written software that does this, but there are some examples like FBI (framebuffer image viewer). I have recovered the console with ssh and/or SysRQ without rebooting after using buggy software and/or buggy drivers, though.