Overhead of X?
eich at suse.de
Thu Apr 20 09:29:12 PDT 2006
Bilderbeek, Manuel writes:
> > X does a little more than just a memset() of the enitre framebuffer.
> > Filling the entire framebuffer with just one solid color is
> > nothing that
> > the solid fill code in fb (that's what you are using unaccelerated) is
> > really optimized for. Therefore it will perform some tests
> > and operations
> > that are not required for this particular operation.
> Would all those tests take so much CPU that it makes it 3 times slower?
> So, 2/3 of the time is used for calculations and checks?
> After all, the fill code is just supposed to fill a solid rectangle, so
> the filling itself should be comparable. Or not?
memset() is highly optimized to fill one single large range of
memory with a single byte value.
Some implementation use hand crafted machine code for this,
select the right code sequence for the size and alignment of
XDrawRectangle() cannot use a lot of these optimizations or it's
useless to add them for your corner case.
Maybe you want to profile your problem a little better. This
will tell you where the CPU cycles go - instead of letting us
> > Furthermore memset() is ususally higly optimized for your
> > architecture.
> If the fb fill routine would use memset, would that matter? (I don't
> know if it does that, but I don't see why it couldn't...)
It's not feasable as it will only be applicable to a few corner cases
- like yours.
Not very many people are interested in a solid color full screen
> > This seems to be a poor comparison.
> How can I make it better?
Maybe you should look for a more useful less corner case test scenario?
> Maybe running the application in the root window might help? (Could save
> some checks!)
> How would I do that, anyway? (Run a Java app in the root window...)
Well, even if you paint right into the root window your operations will
still observe clipping by children.
More information about the xorg