SDL+opengl and kwin+desktop effects on

[Duncan]

paulo posted on Thu, 07 Jan 2010 04:27:45 +0900 as excerpted:

> I'm developping an application based on opengl+sdl and I noticed that if
> I have desktop effects on, when resizing my sdl window, it run slow and
> tends to crash with a segmentation fault. On the other hand, if I turn
> off the desktop effects, the sdl app runs faster (that was to be
> expected), but does not slow down on resize, and also does not crashes
> (no segfault here).
> 
> Well, I'm not saying that it's kwins fault, since the segfault happens
> in nvidia's libGLcore.so, I was just wondering if I was the only one
> noticing this?

Until recently I was running an old Radeon 9200 (with the native kernel 
and xorg freedomware drivers).  It could do OpenGL but not at the 
resolutions I was running (it was limited to a 2048x2048 box, I'm running 
dual 1920x1200, stacked for 1920x2400), so I was limited to xrender 
compositing.  I updated to a new Radeon hd4650.  It handles upto 
8192x8192 OpenGL, so I'm in no danger of exceeding that any time in the 
/near/ future =:^), but the OpenGL drivers don't have a release yet, so 
I'm compiling straight from git sources.  The OpenGL works, but isn't 
quite stable, and it leaves me with psychedelic background colors on 
various rectangular portions of the screen at times (so definitely buggy, 
but in an "interesting" way!  =:^).

What you're seeing I also saw here, resizing pretty much anything (IOW, 
not just sdl, I've only a single SDL app I run, and it's pretty much 
constant size except for an initial resize as it opens), with my old 
Radeon 9200.  Remember, unless you have show content while resizing off 
(aka you're in "rubber band" resizing mode), with compositing, especially 
translucent windows on as well, the resizing is not just triggering a 
repaint of the resizing window AND portions of the window(s) underneath, 
but ALSO is triggering an adjustment of the compositing, as the size of 
and number of layers of translucency is adjusted.  With my old Radeon 
9200, that was some noticeable work, even with the GPU offloading part of 
it from the CPU.

With the new Radeon hd4650, I've not noticed it as much or at all, 
however.  What I HAVE noticed is that the instability/crashes seem to 
most often occur when my mouse moves to another window.  Focus follows 
mouse, so it's a focus change, and with that, the window translucency 
changes on both windows, along with desaturate and fade effects on the 
window going inactive, and resaturate unfade on the window going active.  
While it's all happening within the programmed effect time (slow, so I 
can see it happen, I had the old one set to instant as anything else was 
DEAD slow) I've chosen for effects, there's obviously still a bug 
somewhere in all that, that very occasionally (say once every few days, 
the computer stays on pretty much all the time) gets triggered by the 
active window changing, due to all those effects happening at once.  But 
of course that's to be expected on what is after all, direct from git, 
unreleased drivers.

So no, you're not the only one to notice such things.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.