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)
 
>  - 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.


>  - Improve the handling of offscreen memory management in
>    XFree86.

        No comment here. Just look at how efficiently Xaccel
        (i.e. Accelerated-X handles pixmaps as generic cacheale
        resource (since about 1995).

>  - 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).


One of the real intresting things for me is that X11 has pretty much
all of the things in place to make it fast, but most people never
bother to read the specs. 

- 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

Reply via email to