Overhead of X?

[Egbert Eich]

Bilderbeek, Manuel writes:
 > Hi,
 > 
 > > 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
the memory. 
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
guess.

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

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

Cheers,
	Egbert.