問題タブ [xlib]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
759 参照

x11 - 紛らわしい_NET_SUPPORTING_WM_CHECK

ウィンドウマネージャを ICCCM 仕様に準拠させようとしています。_NET_SUPPORTING_WM_CHECK アトムの理由を完全に理解しています。これにより、ウィンドウ マネージャーが実行されなくなったときに無効な情報が残らないことが保証されます。

私が理解していないのは、_NET_WM_NAME と _NET_SUPPORTING_WM_CHECK 自体以外に、サポート ウィンドウで _NET_NUMBER_OF_DESKTOPS のような他のアトムが期待されない理由です。

ウィンドウ マネージャーはデータを設定して上書きすることになっていますが、新しいウィンドウ マネージャーが準拠していない場合、これは誤解を招く可能性があります。

0 投票する
1 に答える
294 参照

xlib - XDrawString引数の16ビット制限

XDrawStringのマニュアルページから、 32ビットのx座標とy座標に署名されているようです。

int XDrawString(Display *display, Drawable d, GC gc, int x, int y, char *string, int length);

xとyの両方がどのようにintであるかに注意してください(つまり、少なくともgcc / linux2.6-i386では32ビット符号付き整数)

問題は、(2 ^ 15-1)を渡すとy = 32767、文字列が正しい場所に描画されますが、この値を超えると文字列が描画されないことです。

内部的には32ビット整数が使用されておらず、代わりに16ビットの符号付き整数が座標に使用されていると思われます。

関数が32ビット整数を受け入れることをマニュアルページが示しているように思われる場合、より長い整数を使用できるようにするために回す必要のあるコンパイルオプションはありますか?それとも、これはXlibの制限ですか?

0 投票する
1 に答える
383 参照

c++ - XDrawString が Solaris で機能しない

XDrawStringSolaris 10 と SunOS 2.6 で使用しています。すべてを pixmap に描画してから、最終的な pixmap を出力しています。メソッドは古いバージョンでは機能しますが、新しいバージョンでは機能しないようで、テキストとして何も表示されません。

0 投票する
9 に答える
91396 参照

algorithm - ポリゴンが凸面、非凸面、または複雑であるかどうかを効率的に判断するにはどうすればよいですか?

のマニュアルページからXFillPolygon

  • shapeComplexの場合、パスは自己交差する可能性があります。パス内の隣接する一致点は、自己交差として扱われないことに注意してください。

  • shapeである場合、ポリゴン内のポイントのすべてのペアについて、それらを結ぶ線分はパスと交差しません。クライアントに認識されている場合は、Convexを指定するとパフォーマンスを向上させることができます。凸状ではないパスに凸状を指定すると、グラフィックスの結果は未定義になります

  • shape非凸の場合、パスは自己交差しませんが、形状は完全に凸ではありません。クライアントに認識されている場合、Complexの代わりにNonconvexを指定すると、パフォーマンスが向上する場合があります。自己交差パスに非凸を指定した場合、グラフィックスの結果は未定義です。

塗りつぶしでパフォーマンスの問題が発生してXFillPolygonいます。マニュアルページに示されているように、最初に実行したいステップは、ポリゴンの正しい形状を指定することです。私は現在、安全のためにComplexを使用しています。

ポリゴン(一連の座標で定義される)が凸型、非凸型、または複雑であるかどうかを判断するための効率的なアルゴリズムはありますか?

0 投票する
1 に答える
6074 参照

performance - 多角形の塗りつぶし: ワインディング ルールと偶数奇数ルールのパフォーマンス

複雑な多角形 (つまり、自己交差) の場合、ワインディング規則または偶奇規則のどちらを選択するかによって、多角形の塗りつぶし方法が異なります。

しかし、交差していないポリゴンの場合、Winding と Even Odd の塗りつぶしルールの間にパフォーマンスの違いがあります。実装固有であることは理解していますが、複雑でないポリゴンに対してどのアルゴリズムがより効率的であるかを理解しています。

フォローアップの質問は、これらの各アルゴリズムの複雑さ (つまり、O(what?)) です。パフォーマンスを向上させるために、ポリゴン内のいくつかのポイント (主に重複または同じ線上にあるポイント) を取り除く価値があるかどうかを知りたいです。

PS:それが問題であれば、私はxlibを使用しています

PPS: 別のグラフィックス カードを使用してもパフォーマンスは変わらないため、問題がハードウェアに関連していないことを確認できます

0 投票する
3 に答える
1180 参照

linux - XCreateWindow は、既存のウィンドウと衝突するウィンドウ ID を与える

XCreateWindow を使用してウィンドウを作成するプログラムを作成しました。これは私のシステムや他の多くのシステムでは完全に機能しますが、多くのシステムでは奇妙な問題がいくつか発生しています。たとえば、そこから取得した ID が、プログラムを起動した端末の ID と衝突します。そのような場合、gnome-terminal のウィンドウ ID も 0x2400001 (親がルート) であり、プログラムのウィンドウ ID も 0x2400001 (親もルート) です。何がうまくいかないのでしょうか?

0 投票する
1 に答える
342 参照

transparency - XFillPolygon:ピックスマップを使用せずに塗りつぶしをトランスペントしますか?

XFillPolygonをStippleFillと一緒に使用するとドライバーに問題が発生し、ピックスマップが非常に遅くなります。ドライバープロバイダーも修正の提供が非常に遅いため、回避策が必要です。

XFillPolygonを使用してポリゴンを透明な色で塗りつぶす方法はありますか?

ありがとう

0 投票する
6 に答える
1245 参照

x11 - いまだに xlib を直接使ってプログラムする人

SO に関する xlib 関連のすべての質問に対する回答がないことに驚いています。これは、もはや誰も xlib を直接使用していないためですか、それとも、これらのタイプの質問をする場所が間違っているのでしょうか? 誰も xlib を直接使用していなくても、昔のことを思い出してこれらの質問を手伝ってくれる人がまだいるはずですが、彼らがここにいるようには見えません...

編集: xlib 関連のヘルプを求めるには、他にどのような場所に問い合わせればよいでしょうか?

0 投票する
1 に答える
1754 参照

c++ - Xlib/Xt で「新しいトップ レベル ウィンドウ」イベントを処理する

そのため、トップ レベルのウィンドウがいつ作成されるかを知る必要がある状況にいます。私は Xlib/Xt レベルで作業しており、EWMH 仕様をサポートしていないウィンドウ マネージャーを使用しています。私の考えは、ルート ウィンドウの SubstructureNotify イベントにフックすることです。しかし、物事はそれほど単純ではありません。

問題は、すべての CreateNotify イベントが [b]トップ レベル[/b] ウィンドウの作成に対応しているわけではないことです。だから私がする必要があると思うのは、イベントから取得したウィンドウをテストして、それがトップレベルのウィンドウであることを確認することです。私は近づいたが、いくつかの偽のウィンドウがまだ私のネットを通り抜けている. たとえば、GTK アプリケーションでは、ドロップダウン ボックスがあり、それをクリックすると、新しいウィンドウが作成されますが、それをキャッチして無視する方法がわかりません。このようなウィンドウは、典型的なトップ レベルのアプリケーション ウィンドウと見分けがつかないという厄介な問題を抱えています。

これが私がこれまでに持っているものです:

ロングショットですが、私が試すことができるアイデアはありますか? ここで本当にできることは他にあまり考えられません。