<div class="markdown_content"><ul>
<li><strong>labels</strong>: rendering (e.g. display) --> rendering (e.g. display), linux</li>
<li><strong>Group</strong>: linux --> 0.93.3</li>
</ul>
<hr />
<p><strong> <a href="http://sourceforge.net/p/pd-gem/bugs/202/" class="alink">[bugs:#202]</a> extremely high cpu usage when using GEM in a tiling wm</strong></p>
<p><strong>Status:</strong> open<br />
<strong>Group:</strong> 0.93.3<br />
<strong>Labels:</strong> rendering (e.g. display) linux <br />
<strong>Created:</strong> Fri Dec 14, 2012 09:43 AM UTC by defaultxr<br />
<strong>Last Updated:</strong> Fri Dec 14, 2012 09:43 AM UTC<br />
<strong>Owner:</strong> nobody</p>
<p>I use a window manager called StumpWM, and the default behavior of the window manager is to maximize all windows within their "frame". when i try to open a gem window via the [gemwin] object, the window manager and GEM get stuck in a "resizing fight", with the window manager attempting to resize the GEM window, and GEM attempting to reset the size. it works fine if i use a floating window group (which does not cause the window manager to try resizing the window), but i prefer not to have to do that. it also works if i send a "dimen" message to [gemwin] with the precise dimensions that StumpWM will try to resize the window to, but if i attempt to split the window-frame, the problem comes back.</p>
<hr />
<p>Sent from sourceforge.net because gem-dev@lists.iem.at is subscribed to <a href="https://sourceforge.net/p/pd-gem/bugs">https://sourceforge.net/p/pd-gem/bugs/</a></p>
<p>To unsubscribe from further messages, a project admin can change settings at <a href="https://sourceforge.net/p/pd-gem/admin/bugs/options.">https://sourceforge.net/p/pd-gem/admin/bugs/options.</a>  Or, if this is a mailing list, you can unsubscribe from the mailing list.</p></div>