In your message of 24 October 2002 you write:
>
> 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.
There is nothing in the spec that would not allow such a toplevel
backing store to be used, and reuse that toplevel buffer for all of
it's children.
Again you are mixing up one specific implementation with the
specification behind it. Nobody said that the sample server was that
smart in all it's design decisions.
> In the sample implementation and in XFree86, SaveUnders are
> just "turn on backing store for all overlapped windows".
XFree86 except for the driver layer is pretty much only the sample
implementation reused. Anyhow the SaveUnders implementation based upon
BackingStore is such a HUGE problem. Assmuing you had a 3D window with
direct rendering, then you will not be able to use backing store for
those parts. However save-unders might still work (assuming you didn't
abuse backing store for that).
> 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.
Why would backing store not help there ?
> > > - 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.
Those compilcated mechanism are to be dealt with by the toolkits and
not the applications in the first place. IMHO opaque resizes are
directly possible using this technique.
> > > - 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.
You could do that using DBE. Pretty much exactly this.
> (The fact that software fallbacks for RENDER are happier
> if the destination is in system ram does complicate this)
Please do not mix up again spec with implementation. The RENDER
implementation you are talking about is Keith Packard's, which is SW
only. If you have a decent implementation that uses HW acceleration
you do want to have the destination is HW, whilesource & mask should
be in SW.
- Thomas
--
Thomas Roell /\ Das Reh sprint hoch,
Xi Graphics / \/\ _ das Reh springt weit,
[EMAIL PROTECTED] / / \ \ was soll es tun,
/ Oelch! \ \ es hat ja Zeit.
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
