Thomas Roell <[EMAIL PROTECTED]> writes:
> In your message of 24 October 2002 you write:
>
> >
> > Vadim Plessky <[EMAIL PROTECTED]> writes:
> >
> > > Making the Case for XFree86's Speed
> > > http://www.osnews.com/story.php?news_id=1905
> > > Comments:
> > > http://www.osnews.com/comment.php?news_id=1905
> > >
> > > Would be interesting to know what people on the list think about article
> > > itself and XFree86 speed.
> > > I found original link on BlueEyedOS web page (BeOS clone)
> >
> > I think the author is right that interesting things can be
> > done in the area of performance and X. As far as
> > particular problems that he identifies and solutions he
> > proposes... well, they certainly wouldn't be where I was
> > looking.
> >
> > Quick rundown of what I think _is_ interesting:
> >
> > - Store the full contents of all toplevels. Exposes are an
> > obsolete concept from when window contents were simpler and
> > graphics memory smaller.
> >
> > (You may want to discard information if memory gets tight,
> > but you shouldn't be discarding the contents of a window
> > just because it is obscured or offscreen)
>
> X11 has two concepts already in place that do exactly this:
>
> Backing Store (keep seperate memory for obscured regions)
> Save Unders (save the content under a popup window)
These are certainly similar concepts; I haven't completely
done the research to determine what parts of the current
unsuitability of Backing Store is required by the protocol
and what is just what is there in the sample implementation.
One of the main problems with backing store is the fact that
it is per-window, not per-toplevel. And there are some subwindows
where you really don't want to turn it on ... consider the
case where you are scrolling using a really big window clipped
with a small parent. The portions of the window of the window
outside its parent are "obscured" portions and saved by
the X backing store code.
In the sample implementation and in XFree86, SaveUnders are
just "turn on backing store for all overlapped windows".
Partly the reason that I think that fixing Backing Store may
not be the way to go here is that translucent windows are
an inescapable part of the future, any reasonable implementation
of translucent windows has to do saving of obscured portions.
> > - Solve the frame / contents synchronization problem for
> > opaque resizing. When the content of the window can be
> > redrawn at a reasonable rate, there should be no reason
> > that the window appears in an inconsistent state to the
> > user.
>
> Part of this is also already handled in X11 bit the concept of
> gravtiy.
Using bit/window gravity at the application level isn't all
that practical these days... there frequently isn't a separate
window per graphical user interface element, and complicated
layout mechanisms are the rule.
There _are_ some tricks you can play with window and bit gravity
to reduce the jitter you typically get for opaque resizes from
the left and top.
> > - Study how applications and toolkits use offscreen pixmaps;
> > it might be useful to have hinting about whether pixmaps
> > are transient or permanent. (Or possibly push the equivalent
> > of gdk_window_begin_paint()/gdk_window_end_paint() into
> > the server.)
>
> That is an intresting thought. Issues here are when do you
> want a pixmap cached. Sometimes you don't have enough space
> for all pixmaps you'd want (ran into this very problem a few
> days ago with KDE's idea of making the root-background-pixmap
> the whole screen size), and sometimes the hinting is wrong
> (for example you might not want to have a source-picture
> pixmap for RENDER cached).
What I'm particularly thinking of here is being able to get
pixmaps used for double buffering of widget drawing into
video ram, instead of using up all the video ram on big static
pixmaps.
That is, Mozilla/GTK+/etc. typically have the usage pattern:
- Create a pixmap
- Draw on it a bunch with primitives
- Blit it to the window
- Destroy it
You get much mileage out of putting that pixmap in video ram
then you do out of putting the KDE root window pixmap in
video RAM.
(The fact that software fallbacks for RENDER are happier
if the destination is in system ram does complicate this)
Regards,
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
