Re: Does KDE really support XRender?
On Sun, Oct 12, 2003 at 07:00:16PM +0200, Kevin Krammer wrote:
| > One way to avoid having to do full redraw of revieled - (is that
| > spelled correctly btw? I was amazed not being able to find it in my
| > dictionary. :) - areas would be to always have all windows fully
| > rendered and buffered. When you move a window you would then blit the
| > window to the new position and the revieled areas would be blitted from
| > the buffer.
|
| I think Cameron Patrik wrote earlier, that this is how it works already.
Not quite. While the old window contents are blitted across to the new
location, the area behind /isn't/ - X generates exposure events on the
window behind and those windows are responsible for redrawing
themselves, which often involves more than just blitting an image.
Note that this is the same way that most windowing systems work, and
while saving the contents of covered windows may be faster (at the
expense of memory, obviously), other systems seem to cope just fine
without it. That doesn't mean that X's design is necessarily the most
efficient way of handling these window redraws, or that applications
sometimes take too long to repaint themselves.
Also: X /does/ provide a mechanism (called "SaveUnder") whereby
applications can request that their window contents be cached by the X
server. I'm not sure whether this is well implemented or used by any
notable applications.
| > If you cover an IDL visualisation window, the contents are not redrawn.
| > You just get a black window. Though you could say that this is just
| > IDLs fault, I would argue that it really should be the guis job to
| > handle window refreshes.
|
| Well, you are right, it is the GUIs job, so obviously IDLs GUI failed to
| do it properly.
| It either irgnored the expose event or it didn't handle it correctly.
|
| Not grafic system can fix a broken application refusing to draw content.
Yes. Incidentally, MS Windows (the only other windowing system that I'm
familiar with from a programming perspective) programs can easily
exhibit the same behaviour if they don't respond to a WM_PAINT message.
Xlib does make it easier to make broken applications in this manner,
though.
Cameron.
Reply to: