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)
- 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.
- Improve the handling of offscreen memory management in
XFree86.
- 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.)
The actual implementation of the much of the above would
take some serious server re-architecting. Fortunately, it's
largely the same server re-architecting that is needed for
features like translucency / thumbnailing / magnification.
Regards,
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
