XCreateGC函数性能
我对 XCreateGC 函数性能有疑问。似乎在某些情况下工作正常（快速），而在其他情况下则非常慢:)。有关更多详细信息，请查看此代码：
void some_function(int dx, int dy, int sx, int sy, int w, int h,
Drawable src, Drawable mask, Drawable dest)
{
Display *dpy = QX11Info::display();
GC gc = XCreateGC(dpy, src, 0, 0);
XSetClipOrigin(dpy, gc, dx - sx, dy - sy);
XSetClipMask(dpy, gc, mask);
XCopyArea(dpy, src, dest, gc, sx, sy, w, h, dx, dy);
XFreeGC(dpy, gc);
}
提前致谢。
I've a problem with XCreateGC function performance. It seems that works normal(fast) in several cases, and very slow in other cases:). For more details, please look on this code:
void some_function(int dx, int dy, int sx, int sy, int w, int h,
Drawable src, Drawable mask, Drawable dest)
{
Display *dpy = QX11Info::display();
GC gc = XCreateGC(dpy, src, 0, 0);
XSetClipOrigin(dpy, gc, dx - sx, dy - sy);
XSetClipMask(dpy, gc, mask);
XCopyArea(dpy, src, dest, gc, sx, sy, w, h, dx, dy);
XFreeGC(dpy, gc);
}
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Xlib 性能的关键是了解库何时需要阻止来自 X 服务器的回复。一般来说，创建资源（比如GC）不需要阻塞；资源ID在客户端分配，创建请求只是排队或发送，无需等待回复。当 Xlib 调用最终需要回复时，它必须突然停止并等待所有请求完成，获得所有待处理的回复，最后获得当前调用的回复。这将使一个 Xlib 函数看起来超级慢，但实际上您可能会看到一大堆先前函数的成本。
不过，据我所知，XCreateGC 不应该阻止回复。是否有可能由于发送缓冲区已满而阻塞？也许您有大量的请求，并且在某个时刻您的应用程序因阻塞在完整的套接字缓冲区上而停止，直到 X 服务器可以捕获并读取更多请求。
无论如何，因为这个问题已经很老了，所以询问细节可能已经太晚了，但我认为基本的答案是，如果您使用探查器，当 Xlib 实际上正在等待或经历后果时，Xlib 函数调用可能位于堆栈上一些早期 Xlib 函数调用，或者只是您发出的 X 请求的绝对数量。 XCreateGC 本身很可能不是问题。
等待 X 服务器的另一个深奥原因可能是另一个客户端抢占了服务器，这使得服务器无法处理来自其他任何人的请求。
关键策略通常是：
（粗略的经验法则，任何称为 XGetSomething 的东西都必须等待所有待处理的请求完成，然后收集所有回复）这些是 <通常是主要问题，例外是当您执行一些真正繁重的操作（例如移动大量图像数据）时，单个操作可能比操作数或往返阻塞更重要。
The key to Xlib performance is understanding when the library needs to block for a reply from the X server. In general, creating a resource (such as GC) does not require blocking; the resource ID is allocated on the client side, and the create request is simply queued up or sent, with no waiting for a reply. At the time when an Xlib call eventually needs a reply, it will have to suddenly stop and wait for ALL requests up to that point to complete, get replies for everything pending, and finally get the reply for the call at hand. This will make one Xlib function look like it's super slow, but really you're seeing the cost of a whole bunch of previous functions, potentially.
XCreateGC should not block for replies, though, as far as I know. It may be possible that it blocks due to a full send buffer? Perhaps you have a flood of requests and at some point your app stalls while it blocks on a full socket buffer, until the X server can catch up and read more requests.
Anyway since this question is old it's probably too late to ask for details, but I think the basic answer is that if you're using a profiler, an Xlib function call may be on the stack when Xlib is actually waiting for or experiencing the consequences of some earlier Xlib function call, or just the sheer number of X requests you are making. Most likely XCreateGC itself is not the problem.
Another esoteric reason to wait for the X server can be that another client has a server grab, which keeps the server from processing requests from anyone else.
The key strategies are often:
Those are usually the main issues, the exception is when you do some truly heavy operation such as moving lots of image data around, then a single operation can be more important than number of ops or round-trip blocking.